FR3010215A1

FR3010215A1 - Procede de traitement de donnees transactionnelles, dispositifs et programmes d'ordinateur correspondants.

Info

Publication number: FR3010215A1
Application number: FR1358276A
Authority: FR
Inventors: Michel Leger
Original assignee: Compagnie Industrielle et Financiere dIngenierie Ingenico SA
Current assignee: Banks and Acquirers International Holding SAS
Priority date: 2013-08-29
Filing date: 2013-08-29
Publication date: 2015-03-06
Anticipated expiration: 2033-08-29
Also published as: US20160210617A1; EP3039628A2; WO2015028435A2; FR3010215B1; WO2015028435A3; CA2921193A1

Abstract

L'invention se rapporte à un procédé de traitement d'une transaction au sein d'un serveur. Selon l'invention, un tel procédé comprend : - une étape de réception (100) d'une requête de traitement (RqT), en provenance d'un terminal de paiement (TP), connecté audit serveur (SI) par l'intermédiaire d'un réseau de communication ; - une étape d'analyse (200) de ladite requête de traitement (RqT) délivrant au moins un identifiant d'un portefeuille numérique (IPN) et un identifiant d'un utilisateur de portefeuille numérique (IUPN). - une étape de mise en œuvre (300) d'une transaction de paiement à partir dudit identifiant d'un portefeuille numérique (IPN) et dudit identifiant dudit utilisateur de portefeuille numérique (IUPN) et d'au moins un paramètre spécifique (PrS) à un serveur transactionnel (ST) associé audit identifiant de portefeuille numérique (IPN), et connecté audit serveur par un réseau de communication. - une étape de réception (400), en provenance du serveur transactionnel (ST), d'une donnée représentative de l'acceptation ou du refus de la transaction, dite donnée de finalisation (DF). Une étape de transmission (500) de cette donnée de finalisation(DF) audit terminal de paiement (TP).

Description

Procédé de traitement de données transactionnelles, dispositifs et programmes d'ordinateur correspondants. 1. Domaine de l'invention L'invention se rapporte au paiement par l'intermédiaire de dispositifs d'utilisateurs.

L'invention se rapporte plus particulièrement au paiement à l'aide d'un dispositif utilisateur qui comprend des moyens pour la mise en oeuvre d'un paiement par l'intermédiaire d'un portefeuille numérique (également appelé portefeuille électronique), lequel est au moins partiellement associé au dispositif utilisateur. Un tel dispositif d'utilisateur peut se présenter sous la forme d'un terminal mobile.

Le paiement par terminal mobile est promu par de nombreux acteurs. Pensé pour être plus pratique et plus sécurisé, ce type de paiement se décline principalement sous deux formes. La première forme utilise une application spécifique du terminal qui renferme des données bancaires, application qui utilise des capacités de transmission de données dite « sans contact » pour se connecter physiquement à un terminal de paiement d'un commerçant et réaliser une transaction de paiement (il s'agit d'une alternative à l'introduction d'une carte de paiement dans un terminal de paiement, avec sous sans utilisation de code PIN). La deuxième forme utilise un identifiant associé au terminal mobile de l'utilisateur. Cet identifiant est utilisé par le possesseur du terminal mobile, conjointement à un code PIN, pour valider la transaction sur le terminal de paiement du commerçant (il s'agit là encore d'une alternative à l'introduction d'une carte de paiement dans le terminal du commerçant). Ces types de paiement permettent de remplacer la carte de paiement pour réaliser physiquement des achats. À ce type d'usage du terminal mobile s'ajoute des usages de paiement qui sont réalisés par l'intermédiaire de portefeuilles électroniques. Ces portefeuilles électroniques sont souvent destinés à réaliser des paiements de petites sommes d'argent chez un commerçant ou encore à effectuer des paiements par internet. Dans ce type d'utilisation, un prestataire de services de paiement, auquel l'utilisateur du terminal mobile a confié des données bancaires, se charge de réaliser le paiement pour le compte de l'utilisateur du terminal. Ce prestataire de services de paiement est souvent différent de l'établissement bancaire auprès duquel l'utilisateur est client. Pour effectuer des paiements en utilisant ce prestataire de services de paiement, l'utilisateur dispose d'un portefeuille numérique (« Wallet » en Anglais), qui est installé sur son terminal (ou au sein d'une carte de paiement dédiée). De son côté, lorsqu'il est commerçant personne physique, le commerçant dispose, sur son terminal, d'une application associée au prestataire de services de paiement pour pouvoir valider le paiement. Ce type de paiement, par l'intermédiaire d'un prestataire de services de paiement, est également réalisé « sans contact », par l'intermédiaire d'une technologie dite « NFC ». 2. Art Antérieur Les prestataires de services de paiement qui proposent des portefeuilles électroniques disposent chacun d'une architecture particulière de traitement de données. Il est donc nécessaire que le terminal de paiement (par exemple de type NFC) du commerçant dispose également d'une application particulière adaptée à chaque prestataire de services de paiement. Ainsi, pour prendre deux exemples, l'architecture de « GoogleTM Wallet » n'est pas la même que l'architecture de « PaypalTM » Wallet. En effet, contrairement à des architectures de portefeuilles comme celles de GoogleTM ou d'IsisTM, où les opérations de crédit/débit des cartes, les offres de fidélité et les informations sont chargés et sécurisées dans le Smartphone ou dans une carte microSD du téléphone, PayPaITM enregistre les données de ses clients sur un cloud. L'application de paiement pour PayPaITM, dans le terminal de paiement du commerçant, est alors complètement différente de l'application de paiement pour GoogleTM ou IsisTM. Comme le développement des solutions de paiement est réalisé sans que les constructeurs de terminaux soient consultés, il en résulte que ces constructeurs doivent s'adapter, tant bien que mal, aux différentes manières de procéder des prestataires de services de paiement. De manière concomitante, les offres émanant des prestataires de services de paiement se multiplient. Le constructeur de terminaux de paiement, sous la pression des commerçant, est donc dans l'obligation d'implémenter, au sien de ses terminaux de paiement de nombreuses applications particulières afin d'assurer que les commerçants pourront répondre aux attentes de leurs clients, quel que soit leur prestataire de services de paiement. Or, l'un des problèmes rencontrés se rapporte à la gestion des parcs des terminaux de paiement. En effet, lorsqu'un prestataire de services de paiement décide de modifier la manière dont est géré le paiement par l'intermédiaire de son portefeuille numérique, le constructeur de terminaux de paiement à l'obligation de modifier l'application qui est utilisée pour ce prestataire dans l'ensemble des terminaux du parc. Un autre problème rencontré réside dans l'obligation d'assurer une transaction dans un temps donné. Or, par exemple dans le cas de PayPaITM, les nombreux échanges qui se produisent au niveau du réseau (le cloud) nécessitent, pour pouvoir réaliser la transaction dans un temps donné, de disposer de réseaux de communication performants, à même de transmettre et recevoir de l'information rapidement. Cela augmente donc les coûts de gestion des portefeuilles numériques chez le commerçant, sans que celui-ci puisse se prévaloir d'une possibilité de répercuter ce coût. En d'autres termes, une partie de coût de traitement de ce type de paiement doit être pris en charge par le commerçant.

Il existe donc un besoin de proposer une technique qui d'une part simplifie la tâche de gestion des constructeurs de terminaux et des gestionnaires de parcs de terminaux. D'autre part, la solution proposée doit limiter les ressources réseaux utilisées pour réaliser les opérations de paiement. 3. Résumé de l'invention La présente technique permet de résoudre aux moins en partie les problèmes susmentionnés. Plus particulièrement, la présente technique se rapporte à un procédé de traitement d'une transaction, au sein d'un serveur, appelé serveur intermédiaire. Le procédé comprend : une étape de réception d'une requête de traitement, en provenance d'un terminal de paiement, connecté audit serveur par l'intermédiaire d'un réseau de communication ; une étape d'analyse de ladite requête de traitement délivrant au moins un identifiant d'un portefeuille numérique et un identifiant d'un utilisateur de portefeuille numérique. une étape de mise en oeuvre d'une transaction de paiement à partir dudit identifiant d'un portefeuille numérique et dudit identifiant dudit utilisateur de portefeuille numérique et d'au moins un paramètre spécifique à un serveur transactionnel associé audit identifiant de portefeuille numérique, et connecté audit serveur par un réseau de communication. une étape de réception, en provenance du serveur transactionnel, d'une donnée représentative de l'acceptation ou du refus de la transaction, dite donnée de finalisation.

Une étape de transmission de cette donnée de finalisation audit terminal de paiement. Ainsi, selon la technique proposée, ce n'est pas le terminal de paiement qui traite la transaction et son déroulement. Cette tâche est effectuée par un serveur, que l'on peut qualifier de serveur intermédiaire ou de serveur mandataire, à qui le terminal de paiement transmet une requête, standardisée, qui comprend au moins certaines des données nécessaires à la mise en oeuvre de la transaction. Il n'est donc plus nécessaire de disposer, au sein du terminal de paiement, d'une pluralité d'application adaptée chacune à un prestataire de service de paiement particulier. Le caractère optionnel des paramètres spécifiques varie en fonction des exigences du serveur transactionnel.

Selon une caractéristique particulière ledit procédé comprend en outre une étape de déchiffrement de la requête de traitement à l'aide d'une clé privée propre audit serveur. Ainsi, on assure que le contenu de la requête ne peut pas être modifié par une entité tierce. La requête est d'abord chiffrée par le terminal de paiement avant d'être transmise au serveur intermédiaire.

Selon un mode de réalisation particulier, ladite étape de mise en oeuvre, par le serveur, d'une transaction de paiement à partir de données de ladite requête de traitement comprend : une étape d'identification dans une base de données, d'un type de portefeuille numérique associé à un utilisateur d'un terminal, à l'aide dudit identifiant de portefeuille numérique transmis par le terminal de paiement ; une étape d'obtention d'au moins un paramètre spécifique nécessaire au déroulement de la transaction ; une étape de chargement d'une instance d'une application particulière, destinée à gérer la transaction auprès du serveur transactionnel ; une étape d'instanciation d'au moins une variable correspondant audit au moins un paramètre spécifique ; une étape de fourniture à ladite au moins une variable à l'application en charge du déroulement de la transaction ; une étape d'obtention d'un résultat de la transaction, sous la forme d'une donnée de finalisation.

Ainsi, le serveur intermédiaire agit, vis-à-vis du serveur transactionnel, comme s'il était un terminal de paiement. Pour le serveur transactionnel, la transaction est réalisée normalement, sans modification des procédures. Selon un mode de réalisation particulier ladite étape de mise en oeuvre, par le serveur, d'une transaction de paiement à partir de données de ladite requête de traitement comprend en outre : une étape d'identification, parmi ledit au moins un paramètre spécifique, d'au moins un paramètre nécessitant au moins une donnée complémentaire absente dudit serveur et nécessaire au déroulement de la transaction ; une étape d'obtention depuis ledit terminal de paiement de ladite au moins une donnée complémentaire. Ainsi, il est possible d'obtenir, de la part du terminal de paiement, des données complémentaires qui peuvent être requises pour mener à bien la transaction de puis le serveur.

Selon une caractéristique particulière ladite au moins une donnée complémentaire appartient au groupe comprenant : une adresse IP dudit terminal de paiement ; une adresse IP d'un terminal d'utilisateur ; une localisation dudit terminal de paiement ; un montant de transaction ; une donnée représentative d'un numéro de compte sur lequel le montant de la transaction doit être prélevé ; signature d'un code de sécurisation individuel ; La présente technique se rapporte également à un serveur de traitement de données transactionnelles de paiement en provenance d'un portefeuille numérique. Ainsi, la technique décrite peut être mise en oeuvre par un serveur. Un tel serveur de traitement d'une transaction comprend : des moyens de réception d'une requête de traitement, en provenance d'un terminal de paiement, connecté audit serveur par l'intermédiaire d'un réseau de communication ; des moyens d'analyse de ladite requête de traitement délivrant au moins un identifiant d'un portefeuille numérique et un identifiant d'un utilisateur de portefeuille numérique. des moyens de mise en oeuvre d'une transaction de paiement à partir dudit identifiant d'un portefeuille numérique et dudit identifiant dudit utilisateur de portefeuille numérique et d'au moins un paramètre spécifique à un serveur transactionnel associé audit identifiant de portefeuille numérique, et connecté audit serveur par un réseau de communication. des moyens de réception, en provenance du serveur transactionnel, d'une donnée représentative de l'acceptation ou du refus de la transaction, dite donnée de finalisation. des moyens de transmission de cette donnée de finalisation audit terminal de paiement. La présente technique se rapporte également à un terminal de paiement apte à gérer des paiements en utilisant des données fournies par un portefeuille numérique. Le portefeuille numérique peut par exemple être matérialisé par un smartphone, lequel comprend, en fonction des architectures, tout ou partie des données nécessaires à la mise en oeuvre du portefeuille numérique. Le smartphone peut également être remplacé par tout autre dispositif permettant de remplir les fonctions susvisées, et notamment permettant de mettre en oeuvre un portefeuille numérique, comme une montre intelligente (« SmartWtach ») ou une paire de lunette intelligente (« SmartGlass »), une carte sans contact (qui dans ce cas agit de manière passive) ou une carte à base de code QR à une ou deux dimensions. Dans au moins un mode de réalisation, la technique se rapporte également à un procédé d'obtention de données transactionnelles, au sein d'un terminal de paiement. Ce procédé comprend les étapes suivantes, postérieurement à une étape d'obtention d'un montant de transaction : une étape d'initiation, par le terminal de paiement, d'une transaction de règlement d'un achat. une étape de réception, à l'aide d'un module de transmission/réception de données du terminal de paiement, d'un identifiant de portefeuille numérique ; une étape de transmission, à l'aide d'un module de transmission/réception de données du terminal de paiement, d'un identifiant d'utilisateur ; une étape d'encapsulation, au sein d'une requête de traitement, dudit identifiant de portefeuille numérique, dudit identifiant d'utilisateur ; une étape de transmission de la requête de traitement à un serveur intermédiaire, postérieurement à une étape d'établissement d'une connexion avec ledit serveur intermédiaire ; une étape de réception d'une donnée de finalisation de transaction. La technique proposée se rapporte également à un dispositif d'obtention de données transactionnelles, installé au sein d'un terminal de paiement. Un tel dispositif comprend: des moyens d'initiation, par le terminal de paiement, d'une transaction de règlement d'un achat. des moyens de réception, à l'aide d'un module de transmission/réception de données du terminal de paiement, d'un identifiant de portefeuille numérique ; des moyens de transmission, à l'aide d'un module de transmission/réception de données du terminal de paiement, d'un identifiant d'utilisateur ; des moyens d'encapsulation, au sein d'une requête de traitement, dudit identifiant de portefeuille numérique, dudit identifiant d'utilisateur ; des moyens de transmission de la requête de traitement à un serveur intermédiaire, postérieurement à des moyens d'établissement d'une connexion avec ledit serveur intermédiaire ; des moyens de réception d'une donnée de finalisation de transaction. Selon une implémentation préférée, les différentes étapes des procédés selon la technique décrite sont mises en oeuvre par un ou plusieurs logiciels ou programmes d'ordinateur, comprenant des instructions logicielles destinées à être exécutées par un processeur de données d'un module relais selon la technique décrite et étant conçu pour commander l'exécution des différentes étapes des procédés. En conséquence, la technique décrite vise aussi un programme, susceptible d'être exécuté par un ordinateur ou par un processeur de données, ce programme comportant des instructions pour commander l'exécution des étapes d'un procédé tel que mentionné ci-dessus. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. La technique décrite vise aussi un support d'informations lisible par un processeur de données, et comportant des instructions d'un programme tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon la technique décrite peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Selon un mode de réalisation, la technique décrite est mise en oeuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels.

Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Un tel composant logiciel est exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, routeur, etc.) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc.). De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, une carte électronique pour l'exécution d'un micrologiciel (firmware), etc. Chaque composante du système précédemment décrit met bien entendu en oeuvre ses propres modules logiciels. Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en oeuvre de la technique décrite. 4. Liste des figures D'autres caractéristiques et avantages de la technique décrite apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 est un diagramme de séquence décrivant la technique proposée ; la figure 2 est un diagramme de séquence décrivant la mise en oeuvre de la transaction depuis le serveur intermédiaire ; la figure 3 est un diagramme de séquence illustrant un deuxième mode de réalisation de la technique proposée ; La figure 4 illustre schématiquement l'architecture technique d'un serveur intermédiaire ; La figure 5 illustre schématiquement l'architecture technique d'un terminal de paiement. 5. Description détaillée de la technique décrite 5.1. Rappel du principe de la technique décrite Le principe général de la technique décrite, comme exposé préalablement, consiste en quelque sorte à abstraire le terminal de paiement de la chaine de paiement lors de la mise en oeuvre d'un paiement par l'intermédiaire d'un portefeuille numérique, tout en conservant les bénéfices de sa présence (par exemple pour l'obtention de données complémentaires, pour la sécurisation de la transaction ou simplement pour rassurer le commerçant et ses clients). En effet, pour le commerçant, qui est finalement la personne physique sur laquelle pèse le plus de contraintes quant à l'utilisation des portefeuilles électroniques (puisqu'il se doit d'accepter tous les portefeuilles existants), il est important que le terminal de paiement qui lui est fourni par l'organisme bancaire avec lequel il travaille ne soit pas le maillon faible de la chaine de paiement. La solution à ce problème est de faire en sorte que le terminal de paiement ne soit pas en charge de la gestion de multiples applications pour permettre le paiement par l'intermédiaire d'un portefeuille numérique. Ceci procure également un avantage certain pour le commerçant : le commerçant n'a pas d'obligation de signer des contrats avec tous les prestataires de services de paiement. Par ailleurs, un serveur intermédiaire, qui remplace le terminal de paiement, joue le rôle de « méta-marchant » vis-à-vis des prestataires de services de paiement, simplifiant ainsi la tâche du commerçant qui n'a plus qu'un seul contrat à signer avec le gestionnaire du « méta-marchant » pour accepter tous les types de portefeuilles numériques gérés par ce gestionnaire.

Ainsi, dans au moins un mode de réalisation de la technique décrite, plutôt que disposer d'une application adaptée à chaque portefeuille numérique, on met en oeuvre, au sein du terminal de paiement, une application dite générique. Cette application générique est capable d'obtenir et de traiter des données spécifiques. Cette application générique comprend des moyens d'obtention d'au moins deux données : un identifiant de portefeuille numérique (code d'identification de service de prestataire de services de paiement, qui permet de savoir à quel prestataire de service de paiement il faut s'adresser pour traiter la transaction) et un identifiant d'utilisateur (ces deux données sont par exemple transmises par le dispositif utilisateur, qui peut être un smartphone, une carte sans contact, une carte à base de code QR). On peut noter, dans une version alternative, que l'identifiant de portefeuille numérique peut également être sélectionné par le commerçant sur le terminal de paiement à partir d'une liste de prestataire de services de paiement disponible par l'intermédiaire du terminal de paiement (cette liste est par exemple transmise par un serveur intermédiaire de manière périodique). Le code d'identification de service est propre au prestataire de services de paiement dont le portefeuille numérique est utilisé. Ce code n'est pas standardisé. Ainsi, le terminal mobile comprend des moyens de recherche de ce code parmi les données transmises par l'application de paiement. L'identifiant de l'utilisateur, pour sa part, n'est pas non plus standardisé. Il est cependant transmis lors de l'initiation de la transaction de paiement. Selon la technique proposée, ces deux données sont transmises par le terminal de paiement, à un serveur intermédiaire, lequel se trouve au sein d'un réseau de communication, et qui traite les données transmises. Les traitements réalisés par le serveur intermédiaire sont principalement les suivants : identification du type de portefeuille numérique utilisé, construction, à partir du type de portefeuille numérique identifié, d'une requête de traitement comprenant l'identifiant de l'utilisateur. L'identifiant de l'utilisateur est formaté selon les attentes d'un serveur transactionnel du prestataire de services de paiement. La requête de traitement est alors transmise au serveur transactionnel, par le serveur intermédiaire, en utilisant une application dédiée. Le serveur transactionnel, sur réception de la requête de traitement, traite la transaction (c'est-à-dire qu'il accepte ou non le paiement pour l'utilisateur) en conjonction avec l'application dédiée du serveur intermédiaire. Ainsi, ce n'est plus le terminal de paiement qui est en charge de la gestion de la transaction avec le prestataire de service de paiement, mais un serveur intermédiaire (ou mandataire) qui reçoit les données nécessaires au traitement de la transaction. Bien entendu, en fonction des attentes des serveurs transactionnels des différents prestataires de services de paiement, les données transmises ne sont pas les mêmes. Dès lors, le serveur intermédiaire peut soit requérir des données complémentaires auprès du terminal de paiement (comme par exemple le montant de la transaction), soit requérir des informations complémentaires auprès du dispositif utilisateur (lorsque celui-ci dispose des capacités pour le faire). Ces informations complémentaires transitent par l'intermédiaire du terminal de paiement, qui fait alors office de passerelle entre le dispositif utilisateur et le serveur intermédiaire. Par la suite, on décrit deux modes de réalisation particuliers pour la mise en oeuvre de la présente technique. Il est clair, cependant, que ces modes de réalisation ne sont pas limitatifs, mais qu'ils représentent uniquement une possibilité de mise en oeuvre adaptée à un contexte technique existant. Ainsi, par exemple, dans le cas où le dispositif utilisateur n'est pas un smartphone, mais par exemple une montre connectée, les échanges qui ont lieu entre le terminal de paiement et la montre connectée peuvent être significativement différents de ceux existants avec un smartphone. L'important, pour la présente technique, étant d'obtenir des données permettant d'abstraire le terminal de paiement tout en étant transparent vis-à- vis du dispositif utilisateur d'une part et du serveur transactionnel du prestataire de services de paiement d'autre part. 5.2. Description d'un mode de réalisation Dans ce mode de réalisation, on décrit le processus permettant de gérer une transaction d'achat d'un ou plusieurs biens ou services au sein d'une boutique d'un commerçant physique à l'aide d'un terminal d'utilisateur (TU) jouant le rôle de dispositif d'utilisateur. Ce mode de réalisation est décrit en relation avec la figure la et la figure lb. Le terminal en question (TU) est un téléphone intelligent, appelé smartphone. Un processus initial, qui prend place au niveau du terminal de paiement comprend : une étape d'obtention du prix à payer (10), par le terminal de paiement (TP) du commerçant ; une étape d'initiation (20), par le terminal de paiement (TP), d'une transaction, ayant pour but le règlement de l'achat. Cette initialisation a pour but de permettre au terminal d'utilisateur de transmettre les données nécessaires au paiement. Elle peut se faire de manière automatique ou par une action du commerçant sur le terminal. de manière complémentaire, pour faciliter la prise en charge par le terminal de paiement des données transmises par le terminal d'utilisateur, le commerçant peut avantageusement sélectionner, parmi une liste de prestataires de services de paiement, le prestataire de service de paiement que l'utilisateur souhaite utiliser. Dans ce cas, avantageusement, le terminal dispose d'une liste de prestataires de services de paiement, qui est mise à jour de manière centralisée et qui est transmise régulièrement, par un serveur intermédiaire, aux différentes terminaux de paiement. Postérieurement à cette étape d'initialisation : une étape de transmission (30), à l'aide d'un module de transmission de données du smartphone, d'un identifiant de portefeuille numérique (IPN) ; une étape de transmission (40), à l'aide d'un module de transmission de données du smartphone, d'un identifiant d'utilisateur (ou d'un compte d'utilisateur) de portefeuille numérique (IUPN). une étape de réception, à l'aide d'un module de transmission/réception de données du terminal de paiement (TP), de l'identifiant de portefeuille numérique ; une étape de transmission, à l'aide d'un module de transmission/réception de données du terminal de paiement (TP), de l'identifiant d'utilisateur. une étape optionnelle de vérification (50) d'une adéquation entre une valeur représentative d'un code de sécurisation (comme un code PIN) saisi par l'utilisateur sur ledit terminal de paiement (TP) et une valeur représentative d'un code de sécurisation présent au sein du terminal de l'utilisateur (TU) (ceci permet de vérifier que l'utilisateur est bien le propriétaire du terminal qu'il souhaite utiliser pour effectuer le paiement). Cette valeur représentative peut-être un hash du code PIN ou une signature de celui-ci. De manière alternative ou complémentaire (par exemple en fonction du montant de la transaction), un mot de passe ou une empreinte digitale peuvent faire office de code de sécurisation. Ces deux dernières possibilités sont plus intéressantes en termes de sécurité que le code PIN, mais peuvent être moins socialement acceptées ; une étape d'encapsulation (60), au sein d'une requête de traitement, dudit identifiant de portefeuille numérique, dudit identifiant d'utilisateur et d'au moins une donnée représentative d'un montant de transaction. Optionnellement, la valeur représentative du code PIN (ou du mot de passe ou de l'empreinte digitale) peut également être encapsulée dans la requête de traitement. Ceci présente l'avantage de pouvoir effectuer une vérification de ces données au niveau du serveur postérieurement à une telle vérification sur le terminal de paiement (TP). Optionnellement, la requête de traitement est chiffrée par un mécanisme de clé publique/clé privée : une clé publique du serveur intermédiaire (SI) est utilisée pour chiffrer la requête de traitement avant sa transmission. Ceci présente l'avantage de diminuer les risques d'interception et de modification des contenus des requêtes de traitement. Ces couples clés publiques/clés privées sont des couples de clés temporaires. Une clé publique temporaire du serveur intermédiaire est transmise régulièrement ou en fonction des besoins au terminal de paiement afin de réduire les risques de compromission. une étape de transmission (70) de la requête de traitement au serveur intermédiaire (SI), postérieurement à une étape d'établissement d'une connexion avec ledit serveur intermédiaire (SI) ; Du point de vue du serveur intermédiaire, la technique objet de la présente divulgation débute par : une étape de réception (100) de la requête de traitement par le serveur intermédiaire (SI) ; optionnellement, une étape de déchiffrement (110) de la requête de traitement à l'aide d'une clé privée du serveur intermédiaire (SI) ; une étape d'analyse (200) de ladite requête de traitement délivrant les données préalablement insérées : identifiant du portefeuille numérique, identifiant de l'utilisateur et optionnellement montant de la transaction et signature du code de sécurisation. une étape de mise en oeuvre (300), par le serveur, d'une transaction de paiement à partir desdites données de ladite requête de traitement et optionnellement d'au moins une donnée spécifique à un serveur transactionnel (ST) désigné par ledit identifiant de portefeuille numérique. Le caractère optionnel de cette donnée spécifique varie en fonction des exigences du serveur transactionnel (ST). une étape de réception (400), par le serveur intermédiaire (SI), en provenance du serveur transactionnel (ST), d'une donnée représentative de l'acceptation ou du refus de la transaction, dite donnée de finalisation. Une étape de transmission (500) de cette donnée de finalisation audit terminal de paiement (TP). une étape de finalisation de ladite transaction par ledit terminal de paiement (TP). Cette étape de finalisation peut consister en l'affichage, sur ledit terminal, de la donnée de finalisation et sur la transmission de cette donnée de finalisation par exemple à une caisse enregistreuse pour comptabilisation de la transaction.

Ainsi, comme exposé dans cette séquence d'étapes, la transaction est menée depuis le serveur intermédiaire (SI). Celui-ci est en quelque sorte perçu comme étant le terminal de paiement (TP) par le serveur transactionnel (ST). Dans ce mode de réalisation, qui présente une situation standard, le serveur intermédiaire (SI) peut : soit charger et exécuter une application (AppT) adaptée au serveur transactionnel (ST) ; soit comprendre directement le code permettant de gérer une transaction avec le serveur transactionnel (ST). Ce choix peut être considéré comme étant un choix de design. En réalité, il répond à un problème spécifique : en fonction du nombre de types de serveurs transactionnels à adresser, la gestion d'un code général permettant d'adresser tous les types de serveurs transactionnel peut être complexe. Par ailleurs, il est également envisageable que les prestataires de services de paiement fournissent leurs propres application (AppT)s. Ainsi, la solution consistant à charger et exécuter une application (AppT) adaptée au serveur transactionnel peut être une solution plus pérenne.

Par ailleurs, en fonction des besoins du serveur transactionnel (ST) pour valider la transaction, des données supplémentaires sont fournies soit par le terminal de paiement (TP) (dans ce cas, ces données sont intégrées à la requête (RqT) transmise par le terminal de paiement (TP)), soit directement par le serveur intermédiaire (SI). Parmi ces données complémentaires, on trouve notamment une localisation du terminal de paiement (TP). En effet, afin de s'assurer que le terminal de l'utilisateur (TU) n'est pas utilisé de manière frauduleuse, le serveur transactionnel (ST) peut vouloir s'assurer que le terminal de paiement (TP) et le terminal de l'utilisateur (TU) se situent dans des zones géographiques identiques. Pour ce faire, le serveur transactionnel (ST) peut se servir de l'adresse IP du terminal de paiement (TP) pour obtenir une localisation (ou d'une autre donnée permettant une localisation, comme une donnée GPS ou une donnée de connexion à une antenne relai de type GSM). Dès lors, dans au moins une mode de réalisation de la technique proposée, on utilise une donnée représentative de l'adresse IP comme donnée de localisation du terminal de paiement (TP). 5.3. Mise en oeuvre d'une transaction de paiement par le serveur intermédiaire (SI) Pour effectuer la transaction, le serveur intermédiaire (SI) émule le comportement du terminal de paiement (TP). On décrit ci-après les différentes étapes permettant de réaliser cette transaction. Cette description est réalisée en relation avec la figure 2. Pour ce faire, le serveur : identifie (310) le type de portefeuille numérique associé à l'utilisateur du terminal mobile (smartphone) dans une base de données, soit à l'aide de l'identifiant de portefeuille numérique (IPN) transmis par le terminal de paiement (TP) soit à l'aide d'une donnée de sélection réalisée préalablement par le commerçant ; obtient (320), par exemple au sein de cette base de données (BDD), les paramètres spécifiques (PrS) nécessaires au déroulement de la transaction. Dans un mode de réalisation particulier, le serveur intermédiaire (SI) peut obtenir ces paramètres (PrS) directement auprès du prestataire de service de paiement identifié. Dans ce cas la base de données comprend au moins une adresse réseaux (par exemple une URI) permettant d'accéder à ces paramètres. optionnellement, requiert (325), auprès du terminal de paiement (TP), des données nécessaires au déroulement de la transaction (adresse, mode de paiement, carte de paiement utilisée -lorsque le portefeuille numérique comprend plusieurs cartes de paiement, ou encore le numéro de compte à utiliser). optionnellement, charge (330) une instance d'une application (AppT) particulière, destinée à gérer la transaction auprès du serveur transactionnel (ST) ; instancie (340) des variables correspondant aux paramètres nécessaires au déroulement de la transaction à l'aide des données obtenues auprès du terminal de paiement (TP) (identifiant de l'utilisateur, optionnellement signature de code de sécurisation, montant de la transaction, etc.) ; fournit (350) ces variables à l'application (AppT) en charge du déroulement de la transaction ; récupère (360) le résultat de la transaction (assertion de la validation ou assertion de rejet) également appelée donnée de finalisation. Ainsi, le serveur intermédiaire (SI) s'est fait passer pour le terminal de paiement (TP). 5.4. Description d'un deuxième mode de réalisation Dans un deuxième mode de réalisation, la transaction est gérée en deux temps. Ce mode de réalisation est décrit en relation avec la figure 3. Les étapes sont communes avec le premier mode de réalisation et ne sont donc pas reprises dans cette description. Leur ordre est modifié. Ces étapes portent les mêmes numéros que dans la figure 1. Dans un premier temps, postérieurement aux étapes 100 et 200, le serveur intermédiaire (SI) effectue directement la transaction (il prend la place du serveur transactionnel (ST) - étape 300X). À partir des données transmises par le terminal de paiement (TP), le serveur intermédiaire (SI) valide donc la transaction (le commerçant est donc crédité de la somme correspondant à l'achat de bien et l'utilisateur du terminal est débité du même montant). Cette validation est effectuée en utilisant une base de données qui sert à comptabiliser les transactions prises en charge par le serveur intermédiaire. Pour le commerçant et pour le client, l'opération de paiement est terminée. Ce mode de réalisation présente l'avantage de ne pas nécessiter un temps de traitement trop long et est adapté aux environnements dans lesquels les débits de transmission de données par réseau (que ce soit un réseau câblé ou un réseau sans fil) sont limités.

Dans un deuxième temps, le serveur intermédiaire (SI) effectue la transaction (étapes 300 et 400) avec le serveur transactionnel (ST) du prestataire de service de paiement. Pour ce faire il utilise l'application (AppT) adaptée à ce prestataire pour effectuer le paiement. Les mêmes données et les mêmes messages sont échangés que dans le cas du premier mode de réalisation. Ainsi le serveur intermédiaire (SI) récupère le montant crédité au commerçant. 5.5. Autres caractéristiques et avantages On présente, en relation avec la figure 4, une architecture simplifiée d'un serveur intermédiaire (SI) apte à mettre en oeuvre la technique décrite. Un tel serveur comprend une mémoire 41, une unité de traitement 42 équipée par exemple d'un microprocesseur, et pilotée par le programme d'ordinateur 43, mettant en oeuvre au moins une partie du procédé tel que décrit. Dans au moins un mode de réalisation, la technique décrite est mise en oeuvre sous la forme d'une application logicielle. Dans un autre mode de réalisation, la technique décrite est mise en oeuvre sous une forme purement matérielle, à l'aide de processeurs et d'interface spécialement créés à cet effet. Un tel serveur comprend : des moyens de réception de message en provenance d'un terminal de paiement ; optionnellement, des moyens de déchiffrement des requêtes de traitement à l'aide d'une clé privée du serveur ; des moyens d'analyse de ladite requête de traitement délivrant les données préalablement insérées : identifiant du portefeuille numérique, identifiant de l'utilisateur et optionnellement montant de transaction et signature de code de sécurisation. des moyens de mise en oeuvre d'une transaction de paiement à partir desdites données de message et optionnellement d'au moins une donnée spécifique désignée par ledit identifiant de portefeuille numérique. des moyens de réception en provenance d'un serveur transactionnel (ST), d'une donnée représentative de l'acceptation ou du refus de la transaction, dite donnée de finalisation. des moyens de transmission de cette donnée de finalisation audit terminal de paiement (TP). Dans au moins un mode de réalisation, la technique décrite peut être mis en oeuvre par l'intermédiaire d'un réseau de communication auquel le serveur est connecté. Dans au moins un mode de réalisation, la technique décrite est mise en oeuvre au sein d'une pluralité de serveurs intermédiaire, par exemple répartis au sein d'un territoire à quadriller. Dans un moins un mode de réalisation de l'invention, le serveur est associé à une base de données. Cette base de données comprend, outre les informations nécessaires à l'identification et à l'exécution des transactions avec les serveurs transactionnels, des données relatives aux commerçants. De telles données, stockées de manière sécurisée dans la base de données, permettent, par exemple à partir d'in identifiant de terminal de paiement, d'obtenir les données nécessaires à l'accomplissement de la transaction au bénéfice du commerçant. Ces données « commerçant » sont par exemple les suivantes : nom du commerçant, adresse physique, domiciliation bancaire, etc. On présente, en relation avec la figure 5, une architecture simplifiée d'un terminal de paiement (TP) apte à mettre en oeuvre la technique décrite. Un tel terminal comprend une mémoire 51, une unité de traitement 52 équipée par exemple d'un microprocesseur, et pilotée par le programme d'ordinateur 53, mettant en oeuvre au moins une partie du procédé tel que décrit. Dans au moins un mode de réalisation, la technique décrite est mise en oeuvre sous la forme d'une application logicielle. Dans un autre mode de réalisation, la technique décrite est mise en oeuvre sous une forme purement matérielle, à l'aide de processeurs et d'interface spécialement créés à cet effet. Un tel terminal comprend : des moyens de réception de données en provenance d'un terminal d'utilisateur. Ces moyens peuvent par exemple consister en un processeur en une antenne sans contact. des moyens d'obtention d'un code d'identification de service et un identifiant d'utilisateur. Ces moyens peuvent être mis en oeuvre par un processeur du terminal qui, à partir des données reçues par le terminal de l'utilisateur, structurant ces données selon plusieurs schémas de structuration possibles ; ces moyens peuvent également être mis en oeuvre en fonction d'une saisie réalisée par le commerçant après interrogation du client sur le type de portefeuille numérique qu'il souhaite utiliser. des moyens de transmission, sous la forme d'une requête, des dites données obtenues par ledit terminal d'utilisateur ; des moyens de réception d'une donnée de finalisation de transaction. Ces moyens sont pilotés par le microprocesseur, à l'aide du programme chargés dans la mémoire du terminal. En fonction des modes de réalisation, le terminal comprend également d'autres moyens permettant de réaliser des échanges avec le serveur intermédiaire et permettant de recevoir de la part de celui-ci des clés de chiffrement temporaires pour réaliser les échanges de données de manière confidentielle.

Claims

REVENDICATIONS1. Procédé de traitement d'une transaction, au sein d'un serveur, procédé caractérisé en ce qu'il comprend : une étape de réception (100) d'une requête de traitement (RqT), en provenance d'un terminal de paiement (TP), connecté audit serveur (SI) par l'intermédiaire d'un réseau de communication ; une étape d'analyse (200) de ladite requête de traitement (RqT) délivrant au moins un identifiant d'un portefeuille numérique (IPN) et un identifiant d'un utilisateur de portefeuille numérique (IUPN). une étape de mise en oeuvre (300) d'une transaction de paiement à partir dudit identifiant d'un portefeuille numérique (IPN) et dudit identifiant dudit utilisateur de portefeuille numérique (IUPN) et d'au moins un paramètre spécifique (PrS) à un serveur transactionnel (ST) associé audit identifiant de portefeuille numérique (IPN), et connecté audit serveur par un réseau de communication. une étape de réception (400), en provenance du serveur transactionnel (ST), d'une donnée représentative de l'acceptation ou du refus de la transaction, dite donnée de finalisation (DF). Une étape de transmission (500) de cette donnée de finalisation(DF) audit terminal de paiement (TP).
2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend en outre une étape de déchiffrement de la requête de traitement (RqT) à l'aide d'une clé privée propre audit serveur (SI) ;
3. Procédé selon la revendication 1, caractérisé en ce que ladite étape de mise en oeuvre (300), par le serveur, d'une transaction de paiement à partir de données de ladite requête de traitement comprend : une étape d'identification (310) dans une base de données, d'un type de portefeuille numérique associé à un utilisateur d'un terminal, à l'aide dudit identifiant de portefeuille numérique (IPN) transmis par le terminal de paiement (TP) ;une étape d'obtention (320) d'au moins un paramètre spécifique (PrS) nécessaire au déroulement de la transaction ; une étape de chargement (330) d'une instance d'une application (AppT) particulière, destinée à gérer la transaction auprès du serveur transactionnel (ST) ; une étape d'instanciation (340) d'au moins une variable correspondant audit au moins un paramètre spécifique (PrS) ; une étape de fourniture (350) à ladite au moins une variable à l'application (AppT) en charge du déroulement de la transaction ; une étape d'obtention (360) d'un résultat de la transaction, sous la forme d'une donnée de finalisation.
4. Procédé selon la revendication 3, caractérisé en ce que ladite étape de mise en oeuvre (300), par le serveur, d'une transaction de paiement à partir de données de ladite requête de traitement comprend en outre : - une étape d'identification, parmi ledit au moins un paramètre spécifique (PrS), d'au moins un paramètre nécessitant au moins une donnée complémentaire absente dudit serveur et nécessaire au déroulement de la transaction ; - une étape d'obtention depuis ledit terminal de paiement (TP) de ladite au moins une donnée complémentaire. 20
5. Procédé selon la revendication 4, caractérisé en ce que ladite au moins une donnée complémentaire appartient au groupe comprenant : - une adresse IP dudit terminal de paiement ; - une adresse IP d'un terminal d'utilisateur ; 25 - une localisation dudit terminal de paiement ; - un montant de transaction ; - une donnée représentative d'un numéro de compte sur lequel le montant de la transaction doit être prélevé ; - signature d'un code de sécurisation individuel ; 30
6. Serveur (SI) de traitement d'une transaction caractérisé en ce qu'il comprend :des moyens de réception (100) d'une requête de traitement (RqT), en provenance d'un terminal de paiement (TP), connecté audit serveur (SI) par l'intermédiaire d'un réseau de communication ; des moyens d'analyse (200) de ladite requête de traitement (RqT) délivrant au moins un identifiant d'un portefeuille numérique (IPN) et un identifiant d'un utilisateur de portefeuille numérique (IUPN). des moyens de mise en oeuvre (300) d'une transaction de paiement à partir dudit identifiant d'un portefeuille numérique (IPN) et dudit identifiant dudit utilisateur de portefeuille numérique (IUPN) et d'au moins un paramètre spécifique (PrS) à un serveur transactionnel (ST) associé audit identifiant de portefeuille numérique (IPN), et connecté audit serveur par un réseau de communication. des moyens de réception (400), en provenance du serveur transactionnel (ST), d'une donnée représentative de l'acceptation ou du refus de la transaction, dite donnée de finalisation (DF). Des moyens de transmission (500) de cette donnée de finalisation(DF) audit terminal de paiement (TP).
7. Procédé d'obtention de données transactionnelles, au sein d'un terminal de paiement, caractérisé en ce qu'il comprend les étapes suivantes, postérieurement à une étape d'obtention d'un montant de transaction : une étape d'initiation (20), par le terminal de paiement (TP), d'une transaction de règlement d'un achat. une étape de réception, à l'aide d'un module de transmission/réception de données du terminal de paiement (TP), d'un identifiant de portefeuille numérique ; une étape de transmission, à l'aide d'un module de transmission/réception de données du terminal de paiement (TP), d'un identifiant d'utilisateur ; une étape d'encapsulation (60), au sein d'une requête de traitement, dudit identifiant de portefeuille numérique, dudit identifiant d'utilisateur ; une étape de transmission (70) de la requête de traitement à un serveur intermédiaire (SI), postérieurement à une étape d'établissement d'une connexion avec ledit serveur intermédiaire (SI) ;une étape de réception d'une donnée de finalisation de transaction.
8. Dispositif d'obtention de données transactionnelles, installé au sein d'un terminal de paiement, caractérisé en ce qu'il comprend : des moyens d'initiation (20), par le terminal de paiement (TP), d'une transaction de règlement d'un achat. des moyens de réception, à l'aide d'un module de transmission/réception de données du terminal de paiement (TP), d'un identifiant de portefeuille numérique ; des moyens de transmission, à l'aide d'un module de transmission/réception de données du terminal de paiement (TP), d'un identifiant d'utilisateur ; des moyens d'encapsulation (60), au sein d'une requête de traitement, dudit identifiant de portefeuille numérique, dudit identifiant d'utilisateur ; des moyens de transmission (70) de la requête de traitement à un serveur intermédiaire (SI), postérieurement à des moyens d'établissement d'une connexion avec ledit serveur intermédiaire (SI) ; des moyens de réception d'une donnée de finalisation de transaction.
9. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution d'un procédé de traitement d'une transaction selon la revendication 1, lorsqu'il est exécuté sur un ordinateur.
10. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution d'un procédé d'obtention de données transactionnelles selon la revendication 7, lorsqu'il est exécuté sur un ordinateur.30