FR3008516A1 - Methode de realisation de transaction, terminal et programme d'ordinateur correspondant. - Google Patents

Methode de realisation de transaction, terminal et programme d'ordinateur correspondant. Download PDF

Info

Publication number
FR3008516A1
FR3008516A1 FR1356839A FR1356839A FR3008516A1 FR 3008516 A1 FR3008516 A1 FR 3008516A1 FR 1356839 A FR1356839 A FR 1356839A FR 1356839 A FR1356839 A FR 1356839A FR 3008516 A1 FR3008516 A1 FR 3008516A1
Authority
FR
France
Prior art keywords
transaction
merchant
terminal
user
identifier
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
FR1356839A
Other languages
English (en)
Inventor
Michel Leger
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Worldline MS France
Original Assignee
Compagnie Industrielle et Financiere dIngenierie Ingenico SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Compagnie Industrielle et Financiere dIngenierie Ingenico SA filed Critical Compagnie Industrielle et Financiere dIngenierie Ingenico SA
Priority to FR1356839A priority Critical patent/FR3008516A1/fr
Priority to FR1363300A priority patent/FR3008518B1/fr
Priority to CA2856282A priority patent/CA2856282C/fr
Priority to EP14176043.9A priority patent/EP2824625B1/fr
Priority to ES14176043T priority patent/ES2865380T3/es
Priority to US14/329,395 priority patent/US11907918B2/en
Publication of FR3008516A1 publication Critical patent/FR3008516A1/fr
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/20Point-of-sale [POS] network systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322Aspects of commerce using mobile devices [M-devices]

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention se rapporte à un procédé de réalisation d'une transaction financière, procédé mis en œuvre au sein d'un terminal d'un utilisateur désirant effectuer une transaction auprès d'un commerçant. Selon l'invention, un tel procédé comprend: - une étape de réception (100) d'un identifiant de commerçant (IdM) ; une étape de réception (200) d'une donnée représentative d'un montant de transaction (Px) ; - une étape de génération (300), par le terminal de l'utilisateur, au profit dudit commerçant, d'une transaction (TF) ; - une étape de transmission (400) de ladite transaction (TF) à destination d'un serveur de gestion de transaction (Srv).

Description

Méthode de réalisation de transaction, terminal et programme d'ordinateur correspondant. 1. Domaine de l'invention L'invention se rapporte au domaine des instruments de paiement. Plus particulièrement, l'invention se rapporte à un nouvel instrument de paiement. 2. Art Antérieur L'histoire du paiement est relativement ancienne. Depuis que la monnaie existe, la manière dont cette monnaie peut être échangée pour réaliser un paiement a été au coeur des préoccupations. De nombreux instruments de paiement ont ainsi été créés : la monnaie fiduciaire, en premier lieu, puis des instruments de change et de crédit, comme la lettre de change, le chèque. Plus récemment, la carte bancaire a progressivement révolutionné la manière dont les paiements sont réalisés. Cette révolution tient principalement à la miniaturisation et aux capacités de traitement des processeurs.
On est en effet passé de l'usage de simples cartes à bande magnétique, contenant des données mais n'étant pas en mesure de traiter de l'information, à des cartes à puces comprenant un processeur et de la mémoire. En revanche, les principes de paiement, en eux même, ont relativement peu évolué par rapport à l'évolution des techniques mises en oeuvre pour réaliser ces paiements. Ainsi, par exemple, pour ce qui est du paiement par carte bancaire, l'utilisateur dispose d'une carte et le commerçant d'un terminal de paiement qui est utilisé pour lire des données de carte et vérifier l'identité du porteur de carte (ou à tout le moins que le porteur de carte connaisse les informations permettant de valider le paiement). Bien que les techniques d'identification, de reconnaissance, de détection de cartes ont évolué, il est toujours nécessaire que l'utilisateur dispose d'un identifiant bancaire qu'il présente au commerçant, charge à celui-ci de disposer des infrastructures nécessaires à l'authentification de l'utilisateur et au passage de transactions auprès des services bancaires adéquat. Or, ces infrastructures d'une part sont couteuses et d'autres part comprennent des données extrêmement sensibles, comme par exemple des identifiants bancaires « de tous les utilisateurs de ce terminal » dont la compromission peut avoir des conséquences autrement plus graves que celles qui sont liées à l'utilisation non autorisée de données bancaires que d'un seul client (par exemple un vol de numéro de carte bancaire). Pour tenter de se préserver des compromissions ou vols au niveau du commerçant, les terminaux utilisés par ceux-ci sont de plus en plus sophistiqués et bardés de mesures de sécurité. Or, bien que ces mesures soient efficaces, il n'en demeure pas moins que des failles existent toujours. Il est donc nécessaire de proposer des solutions qui permettent de résoudre ces problèmes liés au risque de compromission des données du commerçant. 3. Résumé de l'invention L'invention ne présente pas ces inconvénients des solutions de l'art antérieur. En effet, l'invention se rapporte à un procédé de réalisation d'une transaction financière, procédé mis en oeuvre au sein d'un terminal d'un utilisateur désirant effectuer une transaction auprès d'un commerçant. Selon l'invention, un tel procédé comprend : une étape de réception d'un identifiant de commerçant ; une étape de réception d'une donnée représentative d'un montant de transaction ; une étape de génération, par le terminal de l'utilisateur, au profit dudit commerçant, d'une transaction ; une étape de transmission de ladite transaction à destination d'un serveur de gestion de transaction. Ainsi, la technique proposée permet de gérer la transaction directement au sein du terminal du client. Il n'est donc pas nécessaire de fournir au commerçant les identifiant privés de l'utilisateur. Ceux-ci n'étant pas fourni au commerçant, il n'y a pas de risque qu'une compromission du dispositif du commerçant entraine une compromission des données du client. Inversement, il n'y a pas de risque que le commerçant soit compromis par le dispositif du client.
Selon une caractéristique particulière, ladite étape de génération de ladite transaction comprend une étape de saisie, par ledit utilisateur, d'au moins une donnée représentative d'un identifiant personnel de sécurisation. Ainsi, à la différence d'autres techniques, la technique de l'invention assure que la transaction (donc le paiement) est réalisé en mode « card present » (carte présente), c'est-à-dire comme si une carte bancaire avait été insérée dans le terminal du commerçant. Selon une caractéristique particulière, ledit procédé comprend, postérieurement à ladite étape de transmission, une étape de réception d'une donnée représentative d'une validation de ladite transaction en provenance d'un terminal dudit commerçant. Selon un mode de réalisation particulier, que ladite étape de réception d'un identifiant de commerçant comprend une phase d'appairage avec un terminal dudit commerçant comprenant une étape d'obtention de ladite donnée représentative de l'identifiant du commerçant. Selon un mode de réalisation particulier, ladite étape de réception d'un identifiant de commerçant comprend une phase de lecture d'un code à barre comprenant une donnée représentative de l'identifiant du commerçant. Selon un mode de réalisation particulier, ladite étape de réception d'un identifiant de commerçant comprend une étape de réception, en provenance d'un serveur distant, d'une donnée représentative de l'identifiant du commerçant. Selon un mode de réalisation particulier, ladite étape de génération d'une transaction comprend : une étape de création, d'un enregistrement spécifique comprenant d'une part ledit identifiant de commerçant, ladite donnée représentative d'un montant de transaction et une donnée représentative d'un identifiant de l'utilisateur ; - une étape de chiffrement dudit enregistrement à l'aide dudit terminal dudit utilisateur, délivrant ladite transaction.
Dans une autre mode de réalisation, l'invention se rapporte également à un dispositif de construction de données représentatives d'une transaction financière, dispositif mis en oeuvre au sein d'un terminal d'un utilisateur désirant effectuer une transaction auprès d'un commerçant, dispositif caractérisé en ce qu'il comprend : des moyens de réception d'un identifiant de commerçant ; des moyens de réception d'une donnée représentative d'un montant de transaction ; des moyens de génération, par le terminal de l'utilisateur, au profit dudit commerçant, d'une transaction ; des moyens de transmission de ladite transaction à destination d'un serveur de gestion de transaction. Selon une implémentation préférée, les différentes étapes des procédés selon l'invention 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 l'invention et étant conçu pour commander l'exécution des différentes étapes des procédés. En conséquence, l'invention 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. L'invention 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 l'invention 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, l'invention 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'a 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 l'invention. 4. Liste des figures D'autres caractéristiques et avantages de l'invention 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 présente un synoptique de la technique proposée ; la figure 2 décrit un dispositif pour la mise en oeuvre de la technique proposée. 5. Description 5.1. Rappel du principe général de l'invention Le principe général de l'invention repose sur une inversion de paradigme pour ce qui est du paiement. Plus particulièrement, le paiement par carte bancaire à puce (ou carte sans contact, ou téléphone avec fonction de paiement), tel qu'il est couramment réalisé suppose que le commerçant chez qui on souhaite réaliser le paiement dispose d'un équipement spécifique permettant de réaliser le paiement. Ceci suppose également que le client fournisse un identifiant (par l'intermédiaire d'une carte bancaire [à puce, à bande magnétique, sans contact], d'un terminal) et que le commerçant se charge de réaliser une authentification du client en fonction du matériel qui lui est présenté par le client. Dans la technique proposée, un terminal en possession du client (terminal qui peut être un téléphone, un smartphone, un PDA une tablette, un ordinateur portable ou tout autre dispositif apte à gérer une transaction) est utilisé pour générer et transmettre la transaction financière à un serveur de gestion de transaction (comme un serveur bancaire par exemple). Le commerçant n'utilise plus les coordonnées du client. A l'inverse, le client utilise les coordonnées du commerçant. Ceci présente de nombreux avantages, parmi lesquels l'assurance que les données du client ne seront pas volées ou compromises. En effet, dans la mesure où l'on considère que les données du commerçant peuvent être des données publiques et que l'opération financière est une opération à destination du commerçant (opération de crédit pour le commerçant), il n'est pas nécessaire que le commerçant donne son accord pour recevoir un crédit de la part de l'utilisateur. Les données du commerçant ne sont donc pas compromises. De plus, comme le client ne fournit pas ses propres donnés au commerçant, la méthode proposée assure que les données du client ne seront pas exploitées contre son consentement (par vol, usurpation d'identité, etc.). Ainsi, ni le commerçant, ni le client n'ont fourni de données sensibles. Par ailleurs, la technique proposée présente l'avantage d'utiliser les infrastructures existantes au niveau du commerçant. En effet, celui-ci possède déjà, en règle générale, un terminal qui permet de recevoir des données de la part d'un ou plusieurs serveurs bancaires. L'avantage de la méthode proposée est que le terminal du commerçant n'est plus responsable de la construction de la transaction, et qu'il se contente de recevoir des données de la part d'un serveur (et ou d'un autre terminal). Par la suite, on présente un mode de réalisation de l'invention dans lequel le principe présenté est mis en oeuvre. Il est entendu que la mise en oeuvre du principe proposée n'est pas limitative et que toute autre méthode mettant en oeuvre ce principe entre dans le cadre de la présente divulgation. 5.2. Description d'un mode de réalisation Dans ce mode de réalisation, on décrit un procédé permettant à un client de réaliser une transaction financière (par exemple un achat) auprès d'un commerçant. Le système décrit présente l'énorme avantage d'une part de bénéficier des infrastructures existantes et d'autres part d'assurer que la transaction est réalisée en mode « card present » (carte présente), puisque la technique, dans ce mode de réalisation, nécessite la saisie, par l'utilisateur, d'un une donnée représentative d'un identifiant personnel de sécurisation (par exemple d'un code PIN). Ce code PIN est associé, à volonté, soit à une carte de paiement, dissociée du terminal de l'utilisateur, soit directement au terminal de l'utilisateur lui-même (lorsque ce terminal comprend par exemple une carte de paiement ou un module de paiement intégré dans le terminal). Dans ce mode de réalisation, le procédé comprend, au sein d'un terminal détenu par un utilisateur (TU) souhaitant effectuer une transaction financière auprès d'un commerçant (lequel possède un dispositif pouvant être assimilé à un terminal commerçant (TC) qui comprend éventuellement des fonctions réduites) : une étape de réception (100) d'un identifiant de commerçant (IdM); une étape d'obtention réception (200) d'une donnée représentative d'un montant de transaction (Px); une étape de génération (300), par le terminal de l'utilisateur, au profit dudit commerçant, d'une transaction (TF) à destination d'un serveur de gestion de transaction (Srv); une étape de transmission (400) de ladite transaction (TF) au dit serveur de transaction (Srv). Ainsi, le commerçant fourni en quelque sorte un identifiant « public» avec lequel il souhaite que la transaction dont le terminal du client a la charge soit réglée. Dans un mode de réalisation complémentaire de l'invention, l'identifiant fourni par la commerçant permet uniquement de réaliser de transactions de crédit vers un compte ouvert à destination du commerçant. Une fois la transaction transmise au serveur, celle-ci est validée (500). Cette validation peut prendre plusieurs formes distinctes : soit une transmission (501) au terminal du commerçant (TC), qui retransmet au terminal du client (502). Il peut aussi s'agir d'une transmission directe, par le serveur, aux deux terminaux (ceci permet d'éviter les soupçons de fraude pouvant peser sur la transaction). En fonction des modes de réalisation de la technique proposée, la réception de l'identifiant en provenance du commerçant peut comprendre l'une (voire plusieurs) des phases suivantes : une phase d'appairage, par exemple en utilisant le protocole bluetooth, comprenant l'obtention d'une donnée représentative de l'identifiant du commerçant ; une phase de lecture d'un code à barre, par exemple d'un code à barre en deux dimensions, comprenant une donnée représentative de l'identifiant du commerçant ; une étape de réception, en provenance d'un serveur distant, d'une donnée représentative de l'identifiant du commerçant ; dans un mode de réalisation particulier, l'identifiant est obtenu par déchiffrage d'un code à barre, par exemple un code à barre en deux dimensions, (ou appairage bluetooth) délivrant une adresse auprès de laquelle le terminal de l'utilisateur peut obtenir un identifiant du commerçant ; La réception de cet identifiant peut également être réalisée par une carte sans contact, qui, lorsqu'elle est approchée du terminal de l'utilisateur, délivre l'identifiant du commerçant. La réception de cet identifiant peut également être réalisée par un terminal mobile en possession du commerçant lui-même qui échange des données avec le terminal de l'utilisateur.
En fonction des modes de réalisation de la technique proposée, l'obtention d'une donnée représentative d'un montant de transaction peut comprendre l'une (voire plusieurs) des phases suivantes : - une saisie de l'utilisateur lui-même du montant de la transaction ; une phase d'appairage, par exemple en utilisant le protocole bluetooth, comprenant l'obtention d'une donnée représentative d'un montant de transaction ; une étape de lecture d'un code à barre, par exemple d'un code à barre en deux dimensions, comprenant d'un montant de transaction ; une étape de réception, en provenance d'un serveur distant, d'une donnée représentative d'un montant de transaction ; dans un mode de réalisation particulier, l'identifiant est obtenu par déchiffrage d'un code à barre, par exemple un code à barre en deux dimensions, (ou appairage bluetooth) délivrant une adresse auprès de laquelle le terminal de l'utilisateur peut obtenir d'un montant de transaction ; En fonction des modes de réalisation, les étapes de réception précédentes peuvent être combinées en une seule et même étape.
Lorsque les données relatives au commerçant et au prix sont à disposition du terminal, celui-ci génère la transaction. Pour ce faire, plusieurs possibilités sont envisageables. La première consiste à générer, à l'aide d'une application particulière, un enregistrement spécifique comprenant d'une part les données précédemment obtenues et un identifiant de l'utilisateur. Accessoirement, cet enregistrement peut être chiffré afin de garantir l'intégrité des données qui seront transportées. Lors de cette génération, le code PIN de l'utilisateur est requis, par l'intermédiaire d'une application spécifique de saisie de code PIN, laquelle requiert une action de saisie de la part de l'utilisateur. Ceci peut être réalisé à l'aide d'un clavier physique ou d'un clavier tactile. La transaction est donc réalisée en mode « card present ». L'étape suivante consiste à transmettre, à partir du terminal du client, l'enregistrement à destination d'un serveur transactionnel. Le serveur transactionnel (qui est avantageusement un serveur d'un fournisseur de services de paiement), valide alors la transaction.
La validation de la transaction peut comprendre un certain nombre d'étapes, parmi lesquelles une étape de débit d'un compte de l'utilisateur et une étape de crédit d'une compte du commerçant. Dans un mode de réalisation spécifique, en plus de ces deux étapes (débit/crédit), la validation de la transaction par le serveur comprend préalablement : une étape de transmission, à destination d'un terminal en possession du commerçant, d'au moins une donnée représentative de la transaction, afin que celui-ci puisse s'assurer du montant de la transaction, et la valider (dans ce cas, il y a une étape de validation par le commerçant); une étape de réception, de la part d'un terminal en possession de l'utilisateur client, d'une donnée représentative d'une validation de la transaction par ledit commerçant. Selon les modes de réalisation, la donnée représentative de la transaction reçue par le commerçant peut comprendre : une donnée représentative du montant de la transaction ; une donnée représentative du terminal utilisé par ledit utilisateur pour effectuer la transaction, par exemple la marque du terminal ; une donnée représentative de l'établissement de paiement sélectionné par l'utilisateur pour effectuer la transaction au profit du commerçant. Lorsque le terminal du commerçant (TC) valide la transaction, par exemple par l'appui sur une touche de validation du terminal du commerçant, le terminal du client (TU) reçoit, en provenance du terminal du commerçant (TC) (par exemple si une connexion bluetooth a été construite) ou du serveur transactionnel (Serv), une donnée représentative de la validation de la transaction. Dans le même temps, le serveur exécute les opérations de débit et de crédit nécessaires. 5.3. Autres caractéristiques et avantages On décrit, en relation avec la figure 2, un terminal d'utilisateur mis en oeuvre pour réaliser les transactions selon le procédé décrit préalablement.
Par exemple, le terminal comprend une mémoire 21 constituée d'une mémoire tampon, une unité de traitement 22, équipée par exemple d'un microprocesseur, et pilotée par le programme d'ordinateur 23, mettant en oeuvre un procédé de construction de données représentatives de transaction. À l'initialisation, les instructions de code du programme d'ordinateur 23 sont par exemple chargées dans une mémoire avant d'être exécutées par le processeur de l'unité de traitement 22. L'unité de traitement 22 reçoit en entrée au moins une donnée représentative d'un identifiant d'un commerçant et une donnée représentative d'un montant de transaction. Le microprocesseur de l'unité de traitement 22 met en oeuvre les étapes du procédé de construction de données représentatives de transactions, selon les instructions du programme d'ordinateur 23 pour effectuer une validation de transaction. Pour cela, le dispositif comprend, outre la mémoire tampon 21, des moyens de communications, tels que des modules de communication réseau, des moyens de transmission de donnée et éventuellement un processeur de chiffrement. Dans un mode de réalisation particulier de l'invention, le terminal de l'utilisateur, pouvant être un Smartphone, une tablette, un ordinateur portable, un PDA, intègre des moyens de gestion de transaction tels que décrit précédemment. Ces moyens peuvent se présenter sous la forme d'un processeur particulier implémenté au sein du terminal, ledit processeur étant un processeur sécurisé. Selon un mode de réalisation particulier, ce terminal met en oeuvre une application particulière qui est en charge de la gestion des transactions, cette application étant par exemple fournie par le fabricant du processeur en question afin de permettre l'utilisation dudit processeur. Pour ce faire, le processeur comprend des moyens d'identification uniques. Ces moyens d'identification uniques permettent d'assurer l'authenticité du processeur. Dans un autre mode de réalisation, l'application de gestion installée sur le terminal comprend également d'identification uniques permettent soit d'assurer l'authenticité de l'application soit d'assurer l'identification du porteur du terminal, soit les deux.

Claims (9)

  1. REVENDICATIONS1. Procédé de réalisation d'une transaction financière, procédé mis en oeuvre au sein d'un terminal d'un utilisateur désirant effectuer une transaction auprès d'un commerçant, procédé caractérisé en ce qu'il comprend : une étape de réception (100) d'un identifiant de commerçant (IdM); une étape de réception (200) d'une donnée représentative d'un montant de transaction (Px); une étape de génération (300), par le terminal de l'utilisateur, au profit dudit commerçant, d'une transaction (TF); une étape de transmission (400) de ladite transaction (TF) à destination d'un serveur de gestion de transaction (Srv).
  2. 2. Procédé selon la revendication 1, caractérisé en ce que ladite étape de génération (300) de ladite transaction (TF) comprend une étape de saisie, par ledit utilisateur, d'au moins une donnée représentative d'un identifiant personnel de sécurisation.
  3. 3. Procédé selon la revendication 1, caractérisé en ce que ledit procédé comprend, postérieurement à ladite étape de transmission, une étape de réception d'une donnée représentative d'une validation de ladite transaction en provenance d'un terminal dudit commerçant (TC).
  4. 4. Procédé selon la revendication 1, caractérisé en ce que ladite étape de réception (100) d'un identifiant de commerçant (IdM) comprend une phase d'appairage avec un terminal dudit commerçant (TC) comprenant une étape d'obtention de ladite donnée représentative de l'identifiant du commerçant (Idm).
  5. 5. Procédé selon la revendication 1, caractérisé en ce que ladite étape de réception (100) d'un identifiant de commerçant (IdM) comprend une phase de lecture d'un code à barre comprenant une donnée représentative de l'identifiant du commerçant (Idm).
  6. 6. Procédé de construction de données selon la revendication 1, caractérisé en ce que ladite étape de réception (100) d'un identifiant de commerçant (IdM) comprend une étape de réception, en provenance d'un serveur distant, d'une donnée représentative de l'identifiant du commerçant (Idm).
  7. 7. Procédé de construction de données selon la revendication 1, caractérisé en ce que ladite étape de génération (300) d'une transaction (TF) comprend : une étape de création, d'un enregistrement spécifique comprenant d'une part ledit identifiant de commerçant (IdM), donnée représentative d'un montant de transaction (Px) et une donnée représentative d'un identifiant de l'utilisateur; une étape de chiffrement dudit enregistrement à l'aide dudit terminal dudit utilisateur, délivrant ladite transaction (TF).
  8. 8. Dispositif de réalisation d'une transaction financière, dispositif mis en oeuvre au sein d'un terminal d'un utilisateur, dispositif caractérisé en ce qu'il comprend : des moyens de réception (100) d'un identifiant de commerçant (IdM); des moyens de réception (200) d'une donnée représentative d'un montant de transaction (Px); des moyens de génération (300), par le terminal de l'utilisateur, au profit dudit commerçant, d'une transaction (TF);des moyens de transmission (400) de ladite transaction (TF) à destination d'un serveur de gestion de transaction (Srv).
  9. 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 réalisation de transaction selon la revendication 1, lorsqu'il est exécuté sur un ordinateur.10
FR1356839A 2013-07-11 2013-07-11 Methode de realisation de transaction, terminal et programme d'ordinateur correspondant. Pending FR3008516A1 (fr)

Priority Applications (6)

Application Number Priority Date Filing Date Title
FR1356839A FR3008516A1 (fr) 2013-07-11 2013-07-11 Methode de realisation de transaction, terminal et programme d'ordinateur correspondant.
FR1363300A FR3008518B1 (fr) 2013-07-11 2013-12-20 Méthode de réalisation, terminal et programme d'ordinateur correspondant.
CA2856282A CA2856282C (fr) 2013-07-11 2014-07-08 Methode de conduite d'une transaction, terminal et programme informatique correspondants.
EP14176043.9A EP2824625B1 (fr) 2013-07-11 2014-07-08 Méthode de réalisation de transaction, terminal et programme d'ordinateur correspondant
ES14176043T ES2865380T3 (es) 2013-07-11 2014-07-08 Método de realización de una transacción, terminal y programa informático correspondiente
US14/329,395 US11907918B2 (en) 2013-07-11 2014-07-11 Method for carrying out a transaction, corresponding terminal and computer program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1356839A FR3008516A1 (fr) 2013-07-11 2013-07-11 Methode de realisation de transaction, terminal et programme d'ordinateur correspondant.

Publications (1)

Publication Number Publication Date
FR3008516A1 true FR3008516A1 (fr) 2015-01-16

Family

ID=49713159

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1356839A Pending FR3008516A1 (fr) 2013-07-11 2013-07-11 Methode de realisation de transaction, terminal et programme d'ordinateur correspondant.

Country Status (1)

Country Link
FR (1) FR3008516A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001063375A2 (fr) * 2000-02-27 2001-08-30 Adamtech Ltd. Systeme et procede de transaction mobile
US20020116329A1 (en) * 2001-02-20 2002-08-22 Serbetcioglu Bekir Sami Systems and methods for approval of credit/debit account transactions using a wireless device
EP2128809A1 (fr) * 2008-05-30 2009-12-02 Luc Stals Dispositif de serveur pour contrôler une transaction, entité principale et entité secondaire
US20120136798A1 (en) * 2010-11-10 2012-05-31 Murgesh Navar Securing mobile transactions

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001063375A2 (fr) * 2000-02-27 2001-08-30 Adamtech Ltd. Systeme et procede de transaction mobile
US20020116329A1 (en) * 2001-02-20 2002-08-22 Serbetcioglu Bekir Sami Systems and methods for approval of credit/debit account transactions using a wireless device
EP2128809A1 (fr) * 2008-05-30 2009-12-02 Luc Stals Dispositif de serveur pour contrôler une transaction, entité principale et entité secondaire
US20120136798A1 (en) * 2010-11-10 2012-05-31 Murgesh Navar Securing mobile transactions

Similar Documents

Publication Publication Date Title
EP3113099B1 (fr) Conteneur de paiement, procédé de création, procédé de traitement, dispositifs et programmes correspondants
EP3243176B1 (fr) Procédé de traitement d'une transaction à partir d'un terminal de communication
FR3028639A1 (fr) Procede de securisation d'un jeton de paiement
EP2619941A1 (fr) Procede, serveur et systeme d'authentification d'une personne
WO2015028435A2 (fr) Procede de traitement de donnees transactionnelles, dispositifs et programmes d'ordinateur corrrespondants
EP3163487B1 (fr) Procédé de sécurisation de traitement de données transactionnelles, terminal et programme d'ordinateur correspondant
WO2020064890A1 (fr) Procede de traitement d'une transaction, dispositif, systeme et programme correspondant
EP3991381B1 (fr) Procédé et système de génération de clés de chiffrement pour données de transaction ou de connexion
EP3588418A1 (fr) Procédé de réalisation d'une transaction, terminal, serveur et programme d ordinateur correspondant
EP3542335B1 (fr) Procédé de traitement de données transactionnelles, terminal de communication, lecteur de cartes et programme correspondant
EP3485451B1 (fr) Procédé de traitement d'au moins une donnée de moyen de paiement, terminal de paiement et programme d'ordinateur correspondant
EP2824625B1 (fr) Méthode de réalisation de transaction, terminal et programme d'ordinateur correspondant
EP3095223B1 (fr) Méthode de transmission de données chiffrées, méthode de réception, dispositifs et programmes d'ordinateur correspondants
FR2932296A1 (fr) Procedes et dispositif pour entites electroniques pour l'echange et l'utilisation de droits
FR3008516A1 (fr) Methode de realisation de transaction, terminal et programme d'ordinateur correspondant.
EP3570238B1 (fr) Procédé de réalisation d'une transaction, terminal, serveur et programme d'ordinateur correspondant
FR3020166A1 (fr) Procedes de traitement de donnees transactionnelles, dispositifs et programmes correspondants
EP4016427A1 (fr) Procede pour la creation d'un instrument de paiement au profit d'un tiers beneficiaire
FR3031609A1 (fr) Procede de traitement d'une transaction a partir d'un terminal de communication

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

CD Change of name or company name

Owner name: INGENICO GROUP, FR

Effective date: 20170912