FR2963975A1 - Systeme de paiement en ligne - Google Patents

Systeme de paiement en ligne Download PDF

Info

Publication number
FR2963975A1
FR2963975A1 FR1056702A FR1056702A FR2963975A1 FR 2963975 A1 FR2963975 A1 FR 2963975A1 FR 1056702 A FR1056702 A FR 1056702A FR 1056702 A FR1056702 A FR 1056702A FR 2963975 A1 FR2963975 A1 FR 2963975A1
Authority
FR
France
Prior art keywords
user
platform
information
payment
merchant
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
FR1056702A
Other languages
English (en)
Inventor
Didier Perrot
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.)
In Webo Tech
Original Assignee
In Webo Tech
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 In Webo Tech filed Critical In Webo Tech
Priority to FR1056702A priority Critical patent/FR2963975A1/fr
Publication of FR2963975A1 publication Critical patent/FR2963975A1/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/08Payment architectures
    • G06Q20/12Payment architectures specially adapted for electronic shopping 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/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56Financial cryptography, e.g. electronic payment or e-cash

Landscapes

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

Abstract

L'invention se rapporte à des moyens de sécurisation d'une transaction entre un utilisateur titulaire d'un moyen d'identification et un tiers dans un système comprenant en outre; ▪ une plate-forme; et, ▪ un système transactionnel adapté à réaliser la transaction. La plate-forme permet l'authentification de l'utilisateur et la génération de premières informations relatives à l'utilisation du moyen d'identification. Les premières informations comprennent des éléments pour établir une preuve que l'utilisateur a donné son consentement à l'utilisation du moyen d'identification pour la transaction.

Description

SYSTEME DE PAIEMENT EN LIGNE La présente invention se rapporte de manière générale à un système de paiement en ligne. Les systèmes de paiement à distance doivent tout à la fois garantir un niveau de sécurité élevée, quantifiable notamment en termes de risque de fraude ou d'impayés, et préserver d'autre part une simplicité du processus de paiement perçue par l'utilisateur, quantifiable en nombre d'opérations requises ou d'informations demandées à l'utilisateur. Ces exigences sont antagonistes dans les solutions de paiement existantes. En effet, les mesures techniques prises pour réduire la fraude rendent généralement le paiement plus complexe du point de vue de l'utilisateur. A l'opposé, les mesures techniques prises pour simplifier le paiement tendent à rendre les opérations de paiement moins sûres. A titre d'exemple, les solutions basées sur l'authentification du titulaire d'un moyen de paiement lors d'une transaction en ligne, comme celle dénommée « 3D-Secure », multiplient sensiblement par deux le temps nécessaire à la réalisation de ladite transaction. Il en résulte un taux de rejet ou d'abandon élevé, typiquement supérieurs à 10%, et une faible adoption de ces solutions par les commerçants. En outre, ces solutions sont peu adaptées à être utilisées sur un terminal d'ergonomie réduite, tel un téléphone mobile.
De plus, de telles solutions sont particulièrement hétérogènes. A titre d'exemple, dans certains pays, chaque banque émetteur définit son propre dispositif de sécurisation. Il est connu également d'offrir à l'utilisateur la possibilité d'effectuer une transaction en sélectionnant un moyen de paiement précédemment mémorisé par le commerçant. Ce type de transaction, généralement qualifié de paiement en « un clic », présente en revanche un risque de fraude ou d'impayés, car le commerçant ne pouvant pas prouver que l'achat a bien été effectué par un client donné, la transaction est répudiable. Les risques sont alors assumés soit par le commerçant s'il met en oeuvre un moyen de paiement qu'il a mémorisé, soit par le fournisseur du porte-monnaie électronique si une telle solution est mise en oeuvre.
Des solutions intermédiaires visant à conjuguer simplicité de paiement et niveau de sécurité élevé ont été proposées. Les procédés mettant en oeuvre des cartes d'information, ou information cards » en anglais, reposent sur la saisie automatisée des coordonnées d'un moyen de paiement dans le formulaire de paiement. La sécurité desdits procédés peut être améliorée en utilisant pour saisir lesdites cordonnées un service web, fourni par un tiers, adapté pour vérifier la titularité du moyen de paiement. Le tiers doit alors procéder à l'authentification de l'acheteur. Il s'agit alors d'une solution similaire à un porte-monnaie électronique et la sécurisation de la solution de paiement nécessite que l'authentification soit forte. La mise en oeuvre se heurte donc à la difficulté pour ce tiers, lorsqu'il n'est pas lui-même l'émetteur du moyen de paiement, de s'assurer que le titulaire de la carte d'information est bien également le titulaire du moyen de paiement. Cette solution pose en outre le problème de la transmission des coordonnées du moyen de paiement au commerçant, lequel peut s'avérer ne pas être digne de confiance et/ou être victime d'un vol de données. Les procédés de fédération d'identité entre les banques et les commerçants visent à identifier l'acheteur en tant que client du commerçant et en tant que titulaire d'un moyen de paiement utilisable, et ce grâce à des moyens mis en place par l'émetteur. II s'agit là encore d'un schéma similaire à un porte-monnaie électronique émis par la banque. Outre le problème de la transmission au commerçant des coordonnées de paiement, ces procédés soulèvent celui de la protection des données personnelles, car il est nécessaire de définir une identité de l'acheteur partagée entre banques et commerçants. De plus, les commerçants doivent alors supporter des moyens d'authentification mis en place par les émetteurs. Aussi, les problèmes de confiance entre acteurs, de multiplicité des méthodes à supporter, et de répartition des coûts opérationnels ne sont pas résolus.
II existe donc un besoin pour une solution de paiement en ligne, permettant d'une part d'apporter au commerçant un haut niveau de sécurité contre la fraude ou les impayés, et d'autre part de proposer à l'acheteur- utilisateur un processus de paiement simple, notamment en considération du nombre d'opérations nécessaires, de la quantité d'informations à saisir, et d'opérations annexes à effectuer, et plus particulièrement encore lorsque ces saisies ou opérations doivent être réalisées depuis un terminal d'ergonomie réduite. En outre, une telle solution ne devrait pas introduire de contraintes ou limitations lors de l'achat, notamment sur les moyens de paiement supportés. La présente invention vise à améliorer la situation. Selon un premier aspect, il est proposé un procédé de sécurisation d'une transaction entre un utilisateur titulaire d'un moyen d'identification et un tiers 10 dans un système comprenant en outre; ^ une plate-forme; et, ^ un système transactionnel adapté à réaliser la transaction. Le procédé comporte les étapes suivantes, mises en oeuvre par la plate-forme: - une première étape d'authentification de l'utilisateur ; 15 - une deuxième étape de génération de premières informations relatives à l'utilisation du moyen d'identification, les premières informations comprenant des éléments pour établir une preuve que l'utilisateur a donné son consentement à l'utilisation du moyen d'identification pour la transaction. 20 Les premières informations peuvent comprendre des informations signées avec une clé privée permettant d'authentifier la plate-forme, Dans un mode de réalisation, préalablement à la deuxième étape, le moyen d'identification est choisi par exemple par l'utilisateur authentifié, au cours d'une troisième étape, parmi un ensemble de moyens d'identification associés 25 à l'utilisateur, les premières informations permettant en outre d'établir une preuve que l'ensemble est propre à l'utilisateur authentifié. Au cours de la troisième étape, l'utilisateur authentifié peut déclarer un nouveau moyen d'identification non compris dans l'ensemble de moyens d'identification associés à l'utilisateur.
Les premières informations peuvent comprendre en outre des éléments pour établir une preuve que l'utilisateur est titulaire du moyen d'identification. Les premières informations peuvent être filtrées, selon des règles contrôlées par l'utilisateur. Dans un mode de réalisation, un nouveau moyen d'identification est associé à un utilisateur par la plate-forme, sur demande du système transactionnel. La plate-forme peut mettre à disposition une liste de fonctionnalités, associées au nouveau moyen d'identification, lesdites fonctionnalités étant mises à disposition par le système transactionnel. Selon un second aspect, il est proposé une plateforme, adaptée à être couplée à un système transactionnel. Le système transactionnel est adapté à réaliser une transaction entre un utilisateur titulaire d'un moyen d'identification et un tiers. La plateforme comporte : o des moyens d'authentifier l'utilisateur ; o des moyens de générer des premières informations relatives à l'utilisation du moyen d'identification, les premières informations comprenant des éléments pour établir une preuve que l'utilisateur a donné son consentement à l'utilisation du moyen d'identification pour la transaction. Les premières informations peuvent comprendre des informations signées avec une clé privée permettant d'authentifier la plate-forme, Dans un mode de réalisation, la plateforme comporte en outre : o des moyens de sélection, par l'utilisateur authentifié, du moyen d'identification parmi un ensemble de moyens d'identification associés à l'utilisateur, o des moyens d'établissement d'une preuve que l'ensemble est propre à l'utilisateur authentifié, à partir des premières informations. Elle peut alors comporter en outre des moyens de déclaration par l'utilisateur authentifié d'un nouveau moyen d'identification non compris dans l'ensemble de moyens d'identification associés à l'utilisateur. La plateforme peut comporter en outre un moyen d'association d'un nouveau moyen d'identification à un utilisateur par la plate-forme, sur demande du système transactionnel. Selon un troisième aspect, il est proposé un programme d'ordinateur comportant des instructions pour mettre en oeuvre le procédé selon le premier aspect lorsque le programme est exécuté par un ordinateur. Selon un quatrième aspect, il est proposé un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur selon le troisième aspect.
D'autres aspects, buts et avantages de l'invention apparaîtront à la lecture de la description d'un de ses modes de réalisation. L'invention sera également mieux comprise à l'aide des dessins, sur lesquels : - la figure 1 illustre, par un schéma de principe, une architecture du système dans un mode de réalisation ; la figure 2 illustre, par un synoptique, les étapes d'un procédé de sécurisation d'une transaction entre un utilisateur titulaire d'un moyen d'identification et un tiers, selon un mode de réalisation.
Comme illustré sur la figure 1, on considère un premier système selon un mode de réalisation, comprenant une plate-forme 10 de services d'authentification incluant un dispositif de traitement 12, un premier dispositif de stockage 14 adapté pour stocker des données ou secrets utilisés par le dispositif 12 pour l'authentification d'un utilisateur, un deuxième dispositif de stockage 16 adapté pour stocker des données et des règles relatives à des moyens de paiement d'un utilisateur, un dispositif de création de signature électronique 18, et des interfaces 20 de communication et de programmation informatiques. Un système de gestion 24, géré par un commerçant ou ses prestataires, comporte des moyens de traitement 26 adaptés pour gérer l'enregistrement de clients, les sessions, les paniers d'achat ainsi que le paiement de ces derniers. Le premier système comporte des systèmes de paiement 28, 34, comprenant des dispositifs de traitement 30, 36, et des dispositifs de stockage 32, 38 de données et de règles relatives à des moyens de paiement de chaque utilisateur. Les systèmes de paiement 28, 34 fournissent des services de paiement, typiquement pour gérer les demandes d'autorisation ou les transactions de paiement. Un procédé selon un mode de réalisation est représenté sur la figure 2. Au cours d'une première étape 110 d'enregistrement ou « check-in » en anglais, un utilisateur est identifié. Cette première étape est mise en oeuvre par la plate-forme 10, par exemple utilisée par le commerçant pour réserver l'accès à son magasin aux seuls clients identifiés. Au cours de la première étape 110, l'utilisateur est authentifié par la plate-forme 10, par exemple en mettant en oeuvre un procédé d'authentification par certificats cryptographiques, et/ou par utilisation de mots de passe à usage unique ou « One-Time-Password » en anglais, et plus généralement par tout dispositif personnel d'authentification multi-facteur et non-rejouable, mettant préférentiellement en oeuvre la saisie d'un mot de passe ou d'un code PIN par l'utilisateur, non directement transmis à la plate-forme 10. Au cours d'une étape 120, le commerçant, via la plate-forme 10 et l'interface 20, accède à des informations INF relatives à des moyens d'identification de l'utilisateur authentifié, en accédant aux contenus stockés dans le deuxième dispositif de stockage 16. Dans ce mode de réalisation, les moyens d'identification de l'utilisateur sont des moyens de paiement, typiquement des moyens de paiement non-scripturaux, aptes à être mis en oeuvre en ligne de façon répétée car possédant ou associés à une référence individuelle à usage permanent. On peut citer notamment les cartes de débit ou de crédit associées à un numéro de carte, les cartes ou comptes prépayés associés à un numéro de carte ou une référence de compte, les porte-monnaie électroniques associés à une référence pouvant être un identifiant de leur titulaire, les comptes permettant virement ou prélèvement associés à un numéro de compte. Les moyens de paiement de type chèque cadeau peuvent également être pris en compte, dès lors qu'ils font partie d'un chéquier, c'est-à-dire d'une série de chèques distribués à un même utilisateur et possédant une référence globale commune. Les informations INF comportent pour chacun de ces moyens de paiement d'une part des éléments descriptifs ED, et d'autre part des caractéristiques techniques CT. Les caractéristiques CT incluent a minima l'identité du fournisseur de services de paiement FSP supportant le moyen de paiement auquel les informations INF font référence, ainsi que des indicateurs ou descripteurs SER des services supportés par le fournisseur FSP. Le fournisseur de services de paiement désigne l'entité à l'initiative de l'insertion des informations relatives à un moyen de paiement dans le deuxième dispositif de stockage 16 ; le moyen d'identification - ou spécifiquement de paiement - permet d'identifier l'utilisateur vis-à-vis du fournisseur FSP. L'information identifiant le fournisseur FSP contient de façon préférentielle également une adresse de contact de ce fournisseur sous forme par exemple d'un descripteur URL, et la nature de ce fournisseur, telle qu'un émetteur de moyen de paiement, un prestataire de service de paiement PSP ou « payment service provider » en anglais, ou un acquéreur de transactions de paiement. Dans un mode de réalisation, la plate-forme 10 peut appliquer un filtre sur l'information FSP pour restreindre la liste des moyens de paiement auxquels le commerçant accède lors de l'étape 120 à ceux pour lesquels le fournisseur FSP n'est pas un émetteur de moyen de paiement. Dans ce mode de réalisation, la plateforme 10 n'utilise pas nécessairement les indicateurs ou descripteurs de services SER comme critères. La plateforme 10 définit leur format à des fins de communication et de stockage, ledit format n'étant pas nécessairement de taille ni de structure fixe. La plateforme 10 ne définit pas nécessairement leur syntaxe ni leur sens pour le fournisseur FSP et le commerçant, c'est-à-dire la façon de les interpréter ou manipuler.
Dans une étape 130, le commerçant, grâce aux informations INF issues de la plate-forme 10, crée une liste L, éventuellement vide, de moyens de paiement. La sélection s'effectue notamment sur la base des indicateurs ou descripteurs de service SER ainsi que sur la base de l'identité du fournisseur FSP, selon une méthode et des critères de choix propres au commerçant. Dans un mode de réalisation, a minima, l'une des règles de sélection est de ne conserver que des moyens de paiement pour lesquels le fournisseur FSP est une banque ou un PSP du commerçant. Cette règle est préférentiellement appliquée par le système de gestion 24 du commerçant et non par la plate- forme 10 afin d'éviter au commerçant d'avoir à notifier à la plate-forme 10 les changements de banques ou de PSP. Les moyens de paiement de la liste L sont proposés par le commerçant à l'utilisateur afin de payer ses achats en ligne. Les éléments descriptifs ED et éventuellement d'autres éléments issus des informations SER ou propres au commerçant, sont transmis par le commerçant à l'utilisateur afin que ce dernier puisse reconnaître et choisir un moyen de paiement de la liste L, lors d'une étape 140 où la plate-forme 10 est informée de ce choix. Au cours de l'étape 150, le commerçant obtient d'autres informations, via la plate-forme 10, relatives au moyen de paiement MP choisi par 20 l'utilisateur, comprenant : - l'identité de la plate-forme 10 ; des informations SIG signées par la mise en oeuvre par le dispositif de création de signature 18 d'une clé privée de la plate-forme 10 : 25 ^ l'information identifiant le fournisseur FSP ; ^ l'identifiant technique IDT du moyen de paiement MP, préférentiellement crypté en mettant en oeuvre une clé publique du fournisseur FSP ou une clé symétrique si le fournisseur FSP et la plate-forme 10 ont partagé une 30 telle clé ; ^ l'identifiant du commerçant ; ^ un horodatage ; ^ un numéro unique pouvant être défini par le commerçant - tel que le numéro de session de l'utilisateur - ou par la plate-forme 10. Il convient de remarquer que selon un mode de réalisation, le système peut comporter une pluralité de plates-formes 10 ; pour cette raison, les informations fournies par la plate-forme 10 permettent d'une part de la distinguer grâce à la déclaration de son identité, ainsi que de l'identifier de façon certaine grâce à l'emploi d'une infrastructure à clé publique PKI. Ainsi, la plate-forme 10, grâce aux informations SIG, atteste d'une façon non-modifiable et non-imitable par un tiers que l'utilisateur dont le profil dans le dispositif de stockage 16 comporte l'identifiant IDT s'est identifié grâce à un dispositif d'authentification forte vis-à-vis du commerçant désigné par son identifiant, aux date et heure indiquées par l'horodatage. Les informations SIG permettent à l'entité qui en est destinataire de s'assurer de ces faits, dès lors qu'elle accorde sa confiance à la plateforme 10 et à l'autorité de certification ayant délivré un certificat à la plate-forme 10. Dans ce mode de réalisation, les informations SIG ne permettent pas d'être certain que le commerçant ou les systèmes de paiement 28, 34 ne modifient pas le montant de l'achat ou n'échangent pas les paniers d'achat de plusieurs utilisateurs. L'homme de l'art saurait ajouter des moyens pour obtenir ces certitudes supplémentaires, même si ces dernières peuvent être considérées comme non nécessaires du fait que les causes de fraude se situent quasiment exclusivement côté utilisateur et non côté commerçant ou système de paiement. L'utilisation du moyen MP peut nécessiter la saisie supplémentaire par l'utilisateur d'une information SEC faisant partie de l'identifiant complet du moyen de paiement MP, telle que le trigramme affiché au dos d'une carte de paiement, ou une clé RIB. L'information SEC ne recouvre pas les mots de passe ou codes parfois nécessaires pour la mise en oeuvre de moyens de paiement (porte-monnaie électronique, compte-prépayé, carte de paiement lorsqu'une authentification par l'émetteur est mise en oeuvre, etc.) puisque ces mots de passe ne font par partie de l'identifiant complet de ces moyens de paiement (ils sont en particulier modifiables, voire dynamiques). Quand une telle information SEC existe pour le moyen de paiement MP, sa saisie supplémentaire par l'utilisateur reste nécessaire par exemple lorsque pour des raisons règlementaires ou techniques, le fournisseur FSP n'a pas la capacité de stocker l'information SEC. Cette situation, lorsqu'elle se produit, est décrite par un indicateur faisant partie des informations CT afin que le commerçant puisse demander à l'utilisateur de saisir l'information SEC. Le commerçant définit les informations SERC correspondant aux services qu'il demande. La définition de la syntaxe et de la grammaire de demande de service peut être mise en oeuvre dans des contextes où commerçants et fournisseurs ont défini de manière bilatérale la syntaxe et la grammaire des descriptions de services, mais également lorsque cette définition est l'objet d'un consensus ou d'une standardisation. En particulier, certains services peuvent être fournis par défaut. Au cours d'une étape 160, le commerçant insère les informations FSP, SEC, SERC, SIG et identité de la plate-forme 10 dans une transaction de paiement effectuée auprès de son PSP ou de sa banque. Dans ce mode de réalisation, l'identité du fournisseur indiquée dans l'information FSP correspond à cette banque ou à ce PSP. Lorsque la mise en oeuvre du paiement avec le moyen MP requiert une demande d'autorisation, comme généralement pour les paiements par carte, le commerçant insère également, au cours de l'étape 160, les informations liées au moyen de paiement MP dans la demande d'autorisation si celle-ci est envoyée par le système 24. En effet, dans ce cas, ces informations sont nécessaires pour permettre au processeur de la demande d'autorisation d'identifier de quel moyen de paiement il s'agit. Au cours d'une étape 170, le système de paiement 28 vérifie la transaction reçue du commerçant en accédant aux informations contenues dans le dispositif de stockage 32 relatives au moyen de paiement MP désigné par la référence IDT. Cette référence est obtenue par le système de paiement 28 en décryptant les informations SIG ; ce décryptage est possible puisque dans ce mode de réalisation, le système de paiement 28 est opéré par le fournisseur FSP. Contrairement au dispositif de stockage 16 et au système de gestion 24 qui ne contiennent et ne manipulent que des informations non- sensibles relatives au moyen de paiement MP, le dispositif de stockage 32 contient les coordonnées détaillées CD du moyen de paiement MP, c'est-à-dire les informations nécessaires pour réaliser un paiement avec ce moyen. A titre d'exemple, non limitatif, et selon le type de moyen de paiement, il peut s'agir d'un numéro de carte de paiement (PAN) associé au nom de l'utilisateur et à une date d'expiration, ou d'un numéro de compte. Ces informations CD sont le cas échéant complétées par l'information SEC reçue dans la transaction. Le système de paiement 28 peut optionnellement vérifier auprès de la plate-forme 10 le non-rejeu, c'est-à-dire que les informations SIG - en particulier le numéro unique - n'ont pas déjà été reçues pour une autre transaction de paiement. Afin de rendre simples les moyens nécessaires, il n'est procédé à cette vérification que si l'écart entre la date et l'heure de traitement et celles indiquées dans l'horodatage des informations SIG se situent dans un intervalle [MIN ;MAX] où MIN est tel que l'on ne vérifie pas le non-rejeu de transactions « en temps réel » et MAX est tel que l'on ne peut plus vérifier le non-rejeu de transactions au-delà d'un certain délai, ce qui permet de fixer une limite de conservation par la plate-forme 10 des données nécessaires à la vérification. Le stockage des informations SIG par la plate-forme 10 n'est pas nécessaire au-delà du délai MAX ou dès lors que le nonrejeu a été vérifié par le fournisseur FSP. Le fournisseur FSP peut en revanche devoir mémoriser cette information comme moyen de preuve en cas de fraude ou de répudiation sur ce paiement. Associées à l'identité de la plate-forme 10, les informations SIG sont en effet auto-suffisantes, l'intégrité des informations cryptées accessibles dans SIG étant garantie par la mise en oeuvre d'une clé privée de la plate-forme 10. Les délais de conservation par le fournisseur FSP peuvent être déterminés en relation avec les délais légaux (délai de rétractation et délai de recevabilité d'une opposition notamment).
Au cours d'une étape 180, le système de paiement 28 réalise alors le traitement de la transaction et la mise en oeuvre des services. Pour cela, il insère les informations CD et SEC dans la transaction qu'il transmet à l'acquéreur du paiement, et supprime si nécessaire les informations FSP, SEC, SERC et SIG présentes dans la transaction reçue. Le dispositif de stockage 32 contient la version locale des indicateurs ou descripteurs de service SER ; le dispositif de traitement 30 compare cette version locale aux services demandés SERC afin de déterminer selon une méthode qui lui est propre les services réellement mis en oeuvre. Ces services peuvent être propres au paiement tels que le paiement en N fois ou annexes au paiement tels qu'une assurance pour le bien ou service acheté, la garantie du paiement pour le commerçant, un différé du paiement après réception, etc. Dans un mode de réalisation du procédé d'alimentation du dispositif de stockage 16, au cours d'une étape 140, l'utilisateur peut saisir lors du paiement en ligne les informations permettant de payer avec un nouveau moyen de paiement NMP. Lorsque l'utilisateur met en oeuvre un moyen de paiement NMP qu'il n'a pas sélectionné dans la liste L - c'est-à-dire en fait saisit des informations relatives à un moyen de paiement que le commerçant accepte -, le commerçant obtient de la plate-forme 10, au cours de l'étape 150, des informations contenant les éléments suivants : - l'identité de la plate-forme 10 ; - des informations NSIG signées par la mise en oeuvre par le dispositif de création de signature 18 d'une clé privée de la plate-forme 10 : o l'identifiant du commerçant ; o l'identifiant technique provisoire IDTP du moyen de paiement NMP ; o un descriptif technique du moyen de paiement NMP : type et information désignant de façon probable le moyen NMP, telle qu'un extrait du numéro de référence individuel ; o un horodatage ; o un numéro unique pouvant être défini par le commerçant - tel que le numéro de session de l'utilisateur - ou par la plate-forme 10. Les informations NSIG permettent à l'entité qui en est destinataire de s'assurer, dès lors qu'elle accorde sa confiance à la plateforme 10 et à l'autorité de certification ayant délivré un certificat à la plate-forme 10, qu'un utilisateur ayant saisi un nouveau moyen de paiement conforme au descriptif technique contenu dans NSIG chez le commerçant désigné par son identifiant s'est identifié auprès de ce commerçant aux date et heure indiquées par l'horodatage grâce à un dispositif d'authentification forte. Lors d'une étape 160, le commerçant insère NSIG dans la transaction de paiement effectuée auprès de sa banque ou de son PSP. Il convient de remarquer que dans le cas d'un nouveau moyen NMP demandant la mise en oeuvre d'une demande d'autorisation, il n'est pas nécessaire pour le commerçant d'insérer les informations NSIG liées au moyen de paiement dans la demande d'autorisation puisqu'elle contient déjà les informations nécessaires à son routage et à son traitement. Le système de paiement du fournisseur FSP (la banque ou le PSP) traite de façon habituelle la transaction de paiement reçue du commerçant. En marge ou après le paiement proprement dit, lors d'une étape 190, les informations NSIG sont utilisées par le fournisseur FSP afin de valider l'insertion d'informations concernant le moyen de paiement NMP dans le profil de l'utilisateur dans le dispositif de stockage 16 de la plate-forme 10. Préalablement, lors d'une étape 170, le fournisseur FSP doit d'une part vérifier que le moyen de paiement NMP n'est pas déjà stocké dans le dispositif de stockage 32, d'autre part vérifier en mettant en oeuvre une clé publique de la plate-forme 10 la validité de NSIG - notamment que le descriptif technique contenu dans NSIG correspond à celui du moyen de paiement mis en oeuvre dans la transaction. Sous ces conditions, l'une des interfaces 20 est utilisée, au cours de l'étape 190, pour fournir les informations suivantes à la plate-forme 10 : - l'information identifiant le fournisseur FSP; - les informations NSIG reçues : - des informations ASIG signées par la mise en oeuvre d'une clé privée du fournisseur FSP; o un identifiant technique IDT pour le moyen de paiement NMP, préférentiellement crypté en mettant en oeuvre une clé publique de la plate-forme 10 ou une clé symétrique si la plate-forme 10 et le fournisseur FSP ont partagé une telle clé ; o des indicateurs ou descripteurs de service SER que le fournisseur FSP supporte et propose conditionnellement ou inconditionnellement pour ce moyen de paiement NMP; o des éléments descriptifs ED pouvant reprendre le descriptif technique contenu dans les informations NSIG et pouvant le compléter avec une information précisant le type. 20 La plate-forme 10 valide la demande du fournisseur FSP et procède à l'insertion des informations après avoir vérifié la validité des informations ASIG et NSIG reçues. Par ailleurs, le système 28 stocke dans le dispositif de stockage 32 les informations détaillées concernant le moyen de paiement NMP et les services qu'il supporte, au cours d'une étape 190, de façon 25 cohérente par rapport aux informations fournies à la plate-forme 10. Les informations NSIG émises par la plate-forme 10 pour un nouveau moyen de paiement sont différentes des informations SIG fournies pour un moyen de paiement déjà référencé par la plate-forme 10 et sélectionné par 15 l'utilisateur dans la liste L. Ainsi la plate-forme 10 ne peut pas valider une demande d'un fournisseur FSP concernant l'ajout d'un moyen de paiement sélectionné dans la liste L. La plate-forme 10 vérifie également le non-rejeu de la demande du fournisseur FSP grâce au numéro unique et à l'horodatage contenus dans les informations NSIG. Préférentiellement et afin de rendre simples les moyens nécessaires, cette vérification n'aura lieu que si l'écart entre la date et heure de réception de la demande du fournisseur FSP et celles indiquées dans l'horodatage des informations NSIG se situent dans un intervalle [MIN ;MAX] où MIN est tel que l'on ne vérifie pas le non-rejeu de demandes avant l'expiration de ce délai et MAX est tel que l'on ne peut plus vérifier le non-rejeu de demandes au-delà d'un certain délai, ce qui permet de fixer une limite de conservation par la plate-forme 10 des données nécessaires à la vérification. Le stockage des informations NSIG par la plate-forme 10 n'est pas nécessaire au-delà du délai MAX ou dès lors que le non-rejeu a été vérifié. II ne semble pas non plus nécessaire pour le fournisseur FSP de mémoriser ces informations lorsque NSIG ne peut pas servir de moyen de preuve vis-à-vis de tiers que l'utilisateur ayant réalisé le paiement avec le moyen NMP est un porteur autorisé de ce moyen NMP.
La mise en oeuvre des services SER, et en particulier la garantie du paiement au commerçant, nécessite pour le fournisseur FSP de façon complémentaire de s'assurer que l'utilisateur est bien un porteur autorisé du moyen de paiement mis en oeuvre. En effet, lorsque cette assurance n'existe pas, le commerçant - ou bien, selon leurs accords le fournisseur FSP - reste responsable du paiement en cas de fraude ou de répudiation ; alors que lorsque l'assurance existe que l'utilisateur est un porteur autorisé du moyen de paiement, et puisque l'utilisateur a été authentifié fortement pour mettre en oeuvre le moyen de paiement, il devient responsable du paiement en cas de fraude ou de répudiation, c'est-à-dire que le fournisseur FSP peut garantir le paiement au commerçant grâce aux informations SIG conservées. On décrit dans la suite comment cette assurance peut être obtenue.
Dans ce mode de réalisation, le fournisseur FSP est un PSP ou la banque d'un commerçant ; il ne connaît donc pas les utilisateurs et ne peut donc pas les enrôler, c'est-à-dire en particulier leur demander d'apporter une preuve directe.
Selon un premier moyen, direct et employable lorsque le commerçant demande l'authentification du porteur par l'émetteur lors de la saisie du nouveau moyen de paiement NMP, la demande d'autorisation, comportant une information générée par l'émetteur, est reçue par le fournisseur FSP. Lorsque cette information est présente dans une transaction de paiement et atteste de l'authentification réussie du porteur par l'émetteur, le fournisseur FSP acquiert la certitude que l'utilisateur est un porteur autorisé du moyen NMP. Cependant, ce premier moyen requiert deux identifications successives de l'utilisateur, la première par la plate-forme 10 en tant que client du commerçant, la seconde par l'émetteur en tant que porteur du moyen de paiement NMP ; une façon de simplifier pour l'utilisateur ce premier moyen est de ne mettre en oeuvre qu'une identification simple de l'utilisateur du commerçant, consistant en la saisie par l'utilisateur de son identifiant client ; lors du paiement, soit l'utilisateur choisit un moyen de paiement MP de la liste L et est alors authentifié par la plate-forme 10, soit il saisit les informations d'un nouveau moyen NMP et peut alors être authentifié par l'émetteur. Selon un deuxième moyen indirect, le fournisseur FSP ne considère que l'utilisateur est bien un porteur autorisé du moyen NMP qu'après un délai suffisant pour que le titulaire ait eu le temps de faire opposition sur le paiement réalisé avec le moyen NMP. Le fournisseur FSP peut disposer d'un paramètre technique DC traduisant le degré de certitude que l'utilisateur est un porteur autorisé du moyen NMP, et modifie ce paramètre dans le temps selon des règles qui lui sont propres. Le fait que le paramètre DC traduise un degré de certitude nul ou limité à un instant donné ne signifie pas que le fournisseur FSP n'est pas en mesure de garantir le paiement au commerçant : le risque - et donc le coût pour le commerçant - de cette garantie est seulement plus élevé. Il convient de remarquer que le cas particulier d'un degré de certitude nul correspond à la situation courante où le processeur garantit les paiements au commerçant grâce à une assurance. Ce second moyen permet donc au fournisseur FSP de passer continûment d'une garantie du paiement obtenue par un produit d'assurance à une garantie obtenue sans assurance et où le risque résiduel est celui fourni par la méthode d'authentification forte mise en oeuvre par la plate-forme 10. Lors d'une étape 190, le fournisseur FSP peut modifier dans le dispositif de stockage 16 de la plate-forme 10 les informations relatives à un moyen de paiement, puisque notamment dans le contexte du second moyen décrit ci-dessus, les services proposés par le fournisseur FSP évoluent dans le temps. Ainsi, les interfaces 20 de la plate-forme 10 sont adaptées afin de permettre au fournisseur FSP de modifier - voire de supprimer - les informations relatives à un moyen de paiement dans le dispositif de stockage 16. Pour cela, le fournisseur FSP met en oeuvre l'une des interfaces 20 pour fournir les informations suivantes à la plate-forme 10 : l'information identifiant le fournisseur FSP; - des informations MSIG signées par la mise en oeuvre d'une clé privée du fournisseur ; ^ un identifiant technique IDT du moyen de paiement sur lequel porte la modification ou la suppression, préférentiellement crypté en mettant en oeuvre une clé publique de la plate-forme 10 ou une clé symétrique si le fournisseur FSP et la plate-forme 10 en ont partagé une ; ^ un indicateur décrivant le type d'opération souhaitée, modification, ajout ou suppression - le cas échéant, les valeurs des paramètres à ajouter ou modifier - notamment SER, ED. Le dispositif de stockage 16 vérifie la validité de MSIG et la possibilité technique de procéder aux modifications demandées par le fournisseur FSP.
Le fournisseur peut donc mettre en oeuvre des services, en particulier la garantie du paiement pour le commerçant, c'est-à-dire sa sécurisation par rapport à la sensibilité à la fraude où à la répudiation. Cette garantie s'appuie au moins pour partie - dès lors qu'il est devenu certain que l'utilisateur est un porteur autorisé du moyen de paiement - sur une réduction réelle du risque et non sur un simple report du risque du commerçant sur le fournisseur. Simultanément, la mise en oeuvre du moyen de paiement MP se fait de façon particulièrement simple, puisque dès lors que le commerçant a reconnu son client - et ce dans un processus de « check-in » unique et entièrement sous le contrôle du commerçant -, et que des informations non-sensibles concernant des moyens de paiement sont présentes dans le profil de cet utilisateur, le commerçant est en mesure de lui proposer l'utilisation simple d'un ou plusieurs moyens de paiement sans ressaisie d'information par l'utilisateur, quand bien même ce ou ces moyens de paiement n'auraient pas déjà été utilisés chez le commerçant. Dans un mode de réalisation, le fournisseur FSP peut également être un émetteur de moyen de paiement. Lors de l'étape 120, la plate-forme 10 ne filtre pas en fonction de la nature du fournisseur les moyens de paiement stockés dans le dispositif de stockage 16 dont il indique l'existence et la disponibilité au commerçant après que l'utilisateur a été identifié. Ainsi, lors du choix par l'utilisateur du moyen de paiement MP pour lequel le fournisseur FSP est l'émetteur du moyen de paiement, le PSP et l'acquéreur du paiement routent lors d'une étape 160 la transaction de paiement ou la demande d'autorisation vers le fournisseur FSP, s'appuyant pour cela non pas sur le type et la référence du moyen MP - qui ne figurent pas dans la transaction ou la demande - mais sur l'information FSP permettant d'identifier l'émetteur et une façon non-obligatoire de le contacter. Lors d'étapes 170 et 180, les moyens de traitement 36 et de stockage 38 sont utilisés pour vérifier les informations SIG, procéder au paiement et mettre en oeuvre les services SER.
Par ailleurs, afin de s'assurer que l'utilisateur est bien un porteur autorisé du moyen de paiement MP, l'émetteur peut procéder de la manière décrite précédemment dans laquelle le fournisseur FSP est un PSP ou une banque du commerçant. Il peut cependant également mettre en oeuvre un moyen plus direct proposé par la plate-forme 10. II doit pour cela partager ou avoir déjà partagé avec la plate-forme 10 une identité de l'utilisateur, publique au sens où cette identité existe indépendamment de l'émetteur et de la plate-forme 10, ou privée au sens où cette identité n'existe que par rapport à l'émetteur et à la plate-forme 10. Lorsque ce préalable est rempli, l'émetteur met en oeuvre lors d'une étape 190 l'une des interfaces 20 adaptée pour permettre de fournir les informations suivantes à la plate-forme 10 : l'information identifiant le fournisseur FSP; - des informations ESIG signées par la mise en oeuvre d'une clé privée du fournisseur FSP : - une identité de l'utilisateur partagée entre le fournisseur FSP et la plate-forme 10 ; ^ un identifiant technique IDT du moyen de paiement sur lequel porte l'ajout, la modification ou la suppression, préférentiellement crypté en mettant en oeuvre une clé publique de la plate-forme 10 ou une clé symétrique si le fournisseur FSP et la plate-forme 10 en ont partagé une ; ^ un indicateur décrivant le type d'opération souhaitée, ajout, modification, ou suppression ; ^ le cas échéant, les valeurs des paramètres à ajouter ou modifier. L'émetteur et la plate-forme 10 possèdent de nombreuses façons de partager une identité d'un utilisateur. Par exemple, l'émetteur aura confié ou transmis au porteur titulaire du moyen de paiement MP une information CA, information ensuite transmise à la plate-forme 10 via un moyen d'authentification reconnu par la plate-forme 10 ; d'autre part, l'émetteur et la plate-forme 10 auront convenu de l'identité publique ou privée à laquelle cette information CA correspond. Ainsi par ce procédé, la plate-forme 10, identifiant sans ambiguïté l'utilisateur dans son propre référentiel grâce au moyen d'authentification mis en oeuvre, obtient par ailleurs l'identité sous laquelle ce même utilisateur est connu dans le référentiel commun à l'émetteur et à la plate-forme 10. L'émetteur et la plate-forme 10 ont donc partagé une identité d'un utilisateur. Les informations SIG produites par le commerçant via la plate-forme 10 lors de l'étape 160, dans ce mode de réalisation, pour le paiement avec un moyen MP, constituent - ou contiennent les informations permettant de constituer - un mandat de l'utilisateur ; un tel mandat est nécessaire à la réalisation de paiements avec certains types de moyens de paiement, les prélèvements SEPA notamment. La possibilité de constituer un mandat est avérée dès lors qu'il est certain que l'utilisateur est un porteur autorisé du moyen de paiement MP. D'après ce qui a été expliqué ci-dessus, c'est bien le cas dès le premier paiement par prélèvement lorsque le fournisseur FSP est l'émetteur du moyen de paiement MP. Dans un mode de réalisation, le PSP ou la banque auquel le commerçant transmet la transaction de paiement mettant en oeuvre le moyen MP peut également ne pas être le fournisseur FSP pour ce moyen MP, c'est-à-dire que le commerçant ne filtre pas lors de l'établissement de la liste L les moyens de paiement dont le fournisseur FSP n'est pas l'un de ses PSP ou banques. Un tel mode de réalisation requiert d'une part qu'au moins un PSP ou banque du commerçant met en oeuvre pour ce qui le concerne un mode de réalisation de la présente invention, d'autre part que ledit au moins PSP ou banque sait utiliser l'information FSP, soit préférentiellement pour identifier et transmettre au fournisseur FSP, lors d'une étape 160, la transaction de paiement pour que celui-ci la traite selon le procédé précédemment décrit, soit pour obtenir du fournisseur FSP les informations sur le moyen de paiement MP lui permettant de traiter la transaction. La seconde condition ne porte pas sur le fournisseur FSP - puisque s'il implémente un mode de réalisation de l'invention, il fournit dans l'information FSP son identité et une façon d'être contacté - mais sur le dit au moins PSP ou banque. Ainsi, un commerçant mettant en oeuvre ce mode de réalisation, doit préalablement s'assurer que parmi ses PSP ou banques, au moins un implémente un mode de réalisation de l'invention et sait traiter ou transmettre les transactions portant sur des moyens MP dont il n'est pas le fournisseur FSP. Si ce n'est pas le cas, le commerçant ne doit pas inclure le moyen MP dans la liste L qu'il propose à l'utilisateur. Le PSP ou la banque recevant du commerçant une transaction de paiement portant sur un moyen MP ne peut pas valider l'insertion d'informations concernant ce moyen dans le dispositif de stockage 16 de la plate-forme 10, puisque la transaction contient une information SIG et non pas une information NSIG ; par ce moyen, il n'est pas possible de créer dans la plate-forme 10 un moyen de paiement référençant un moyen de paiement déjà référencé dans la plate-forme 10. En revanche, un utilisateur qui déclarerait plusieurs fois un même moyen de paiement NMP via plusieurs PSP ou banques de commerçants aurait dans son profil plusieurs copies du moyen NMP avec des informations FSP différentes. Les interfaces 20 sont adaptées pour que, dans un tel cas, et grâce aux informations ED contenues dans ASIG (reprenant le descriptif technique contenu dans NSIG), la plate-forme 10 enregistre dans le profil de l'utilisateur qu'il s'agit d'un seul et même moyen de paiement, et qu'elle restitue cette information au commerçant dans la liste des informations relatives aux moyens de paiement de l'utilisateur identifié, afin que le commerçant n'insère dans la liste L qu'au plus une référence à ce moyen de paiement, le choix étant effectué par le commerçant sur la base des mêmes critères que ceux déjà énoncés. Dans un mode de réalisation, l'utilisateur n'est pas identifié en tant que client du commerçant mais en tant que porteur d'un portefeuille de moyens de paiement, c'est-à-dire comme utilisateur référencé dans la plate-forme 10. L'identité présentée par l'utilisateur au commerçant lui a été fournie par la plate-forme 10 elle-même, par un commerçant ou par tout autre fournisseur d'identité reconnu par la plate-forme 10. Ce mode de réalisation présente l'avantage spécifique de permettre à un utilisateur n'étant pas déjà client du commerçant de pouvoir mettre en oeuvre le portefeuille de moyens de paiement dont il dispose. Cet avantage en est donc également un pour le commerçant, à la fois parce qu'il peut proposer des paiements simples et garantis à des acheteurs qu'il ne connaîtrait pas déjà comme clients, mais également parce que la mise en oeuvre du portefeuille de moyens de paiement permet au commerçant d'enrôler l'utilisateur comme client. Pour ce faire, la plate-forme 10 peut être adaptée pour communiquer au commerçant une identité publique de l'utilisateur ou convenir avec lui d'une identité privée. Cette identité - publique ou privée - est préférentiellement routable, c'est-à-dire possède une syntaxe conforme à un standard, lui permettant d'être utilisée pour désigner un destinataire d'un message ou d'une communication.
II peut s'agir d'une adresse email, d'une adresse SIP, d'un numéro de téléphone, d'un identifiant de messagerie instantanée, etc. Lorsque l'identité obtenue par le commerçant est routable, le commerçant possède alors un moyen de communiquer avec ce nouveau client. Dans un mode de réalisation, les interfaces 20 de la plate-forme 10 sont adaptées afin de permettre à l'utilisateur d'ajouter, de modifier ou de supprimer les moyens de paiement définis dans son profil dans le dispositif de stockage 16. La plate-forme 10 lui permet ainsi de définir des règles concernant la transmission d'informations relatives à ses moyens de paiement ou son portefeuille de moyens de paiement à des commerçants. Ces règles peuvent notamment être des règles de visibilité - c'est-à-dire de filtrage des moyens de paiement selon des critères tels que la catégorie ou la localisation du commerçant -, elles peuvent également être des règles de contrôle, c'est-à-dire que l'utilisateur devra confirmer son consentement pour que le commerçant obtienne la visibilité sur ses moyens de paiement, ou obtienne les informations concernant le moyen de paiement MP choisi. L'interface 20 est alors adaptée pour qu'un tel consentement de l'utilisateur soit obtenu, par exemple en mettant en oeuvre un protocole de communication de type OAUTH entre le commerçant, la plate-forme 10 et l'utilisateur. La plate-forme 10 lui permet par ailleurs de supprimer ou de masquer un moyen de paiement de son profil. La plate-forme 10 lui permet par ailleurs d'insérer une information prouvant qu'il est bien un porteur autorisé d'un moyen de paiement MP, notamment pour lequel le fournisseur FSP est un PSP ou la banque d'un commerçant. La plate-forme 10 peut notifier au fournisseur FSP une telle insertion, afin que celui-ci mette à jour d'une part l'information DC traduisant le degré de certitude que l'utilisateur est un porteur autorisé du moyen MP, d'autre part les indicateurs ou descripteurs de services SER. La plate-forme 10, si elle respecte les règlementations techniques et de sécurité en la matière peut par ailleurs permettre à l'utilisateur d'insérer directement un nouveau moyen de paiement dans son profil dans le dispositif de stockage 16. La plate-forme 10 est alors le fournisseur FSP désigné pour ce moyen de paiement. Dans un mode de réalisation, l'authentification de l'utilisateur par la plate-forme 10 se fait depuis un terminal différent de celui utilisé pour naviguer sur le site du commerçant. Cela correspond, par exemple, au cas où le terminal de navigation n'est pas un terminal personnel de l'utilisateur (borne de service dans un lieu public tel qu'une gare ou un taxi ; ordinateur d'un cybercafé ; distributeur de monétique ou de billettique ; etc.), ou au cas où il s'agit d'une transaction, à distance ou non, chez un commerçant disposant d'un terminal de paiement électronique (TPE), virtuel ou non adapté pour communiquer avec la carte à puce du moyen de paiement mis en oeuvre, ou bien si le moyen de paiement mis en oeuvre sur ce TPE ne comporte pas de tel dispositif de sécurisation et d'autorisation de la transaction par l'utilisateur.
II peut être souhaitable dans un tel cas que la validation de la partie sensible de la navigation ou de la transaction - à savoir l'acceptation de la transaction par l'utilisateur - soit réalisée à partir d'un terminal personnel de l'utilisateur tel que le téléphone mobile. L'identification par la plate-forme 10 se fait lors de l'entrée en magasin (« check-in »), ou lors du passage en caisse (« check-out »), l'utilisateur s'identifie simplement vis-à-vis du commerçant avec une identité attribuée par un acteur reconnu par la plate-forme 10, à savoir le commerçant, la plate-forme 10 elle-même ou un tiers. L'interface 20 est alors adaptée pour permettre au commerçant de demander à la plate-forme 10 l'authentification de l'utilisateur depuis un terminal différent. Une information concernant cette demande est alors insérée par la plate-forme 10 dans le profil de l'utilisateur. Cette demande est préférentiellement notifiée par la plate-forme 10 à l'utilisateur en utilisant une identité routable de l'utilisateur. L'intérêt et l'avantage de cette notification sont à la fois d'alerter un utilisateur s'il n'est pas l'auteur de la demande chez le commerçant, et de fournir à l'utilisateur un raccourci ou un lien ou une information sur la façon de valider la demande d'authentification à partir d'un terminal différent. Après que l'utilisateur s'est authentifié auprès de la plate-forme 10, le choix d'un moyen de paiement MP dans la liste L ou la saisie d'un nouveau moyen NMP lui sont préférentiellement proposés sur son terminal personnel, l'interface 20 ayant été adaptée pour permettre les échanges d'informations entre le commerçant et la plate-forme 10 concernant d'une part la liste L élaborée par le commerçant à partir des informations INF fournies par la plate-forme 10, d'autre part les choix de l'utilisateur. Cette partie de la navigation de l'utilisateur après authentification depuis un terminal personnel demeure également réalisable à partir du terminal de navigation chez le commerçant. Dans un mode de réalisation, les moyens d'identification associés à l'utilisateur dans son profil stocké par le moyen 16 désignent l'utilisateur dans le référentiel de fournisseurs de services tiers. Les informations SIG obtenues par le système 24 permettent à ce dernier d'accéder aux comptes de cet utilisateur chez ces fournisseurs de services, sans nécessiter de réauthentification voire de nouveau consentement de l'utilisateur, et sans non plus nécessiter que l'utilisateur confie au système 24 ses codes d'identification auprès des fournisseurs de services. Comme décrit dans les modes de réalisation précédents, les services disponibles pour le système 24 lors de cet accès peuvent avoir été décrits dans le moyen 16 et les droits d'accès du système 24 peuvent avoir été définis, notamment par l'utilisateur, dans le moyen 16.

Claims (15)

  1. REVENDICATIONS1. Procédé de sécurisation d'une transaction entre un utilisateur titulaire d'un moyen d'identification et un tiers dans un système comprenant en outre; ^ une plate-forme (10) ; et, - un système transactionnel (24 ; 28, 34) adapté à réaliser la transaction; caractérisé en ce qu'il comporte les étapes suivantes, mises en oeuvre par la plate-forme (10) : - une première étape (110) d'authentification de l'utilisateur ; ^ une deuxième étape (150) de génération de premières informations relatives à l'utilisation du moyen d'identification, les premières informations comprenant des éléments pour établir une preuve que l'utilisateur a donné son consentement à l'utilisation du moyen d'identification pour la transaction.
  2. 2. Procédé selon la revendication 1, dans lequel, les premières informations comprennent des informations signées avec une clé privée permettant d'authentifier la plate-forme,
  3. 3. Procédé selon la revendication 1 ou 2, dans lequel, préalablement à la deuxième étape, le moyen d'identification est choisi par l'utilisateur authentifié, au cours d'une troisième étape (120, 130, 140), parmi un ensemble (L) de moyens d'identification associés à l'utilisateur, les premières informations permettant en outre d'établir une preuve que l'ensemble est propre à l'utilisateur authentifié.
  4. 4. Procédé selon la revendication 3, dans lequel au cours de la troisième étape, l'utilisateur authentifié déclare un nouveau moyen d'identification non compris dans l'ensemble de moyens d'identification associés à l'utilisateur.
  5. 5. Procédé selon l'une quelconque des revendications 1 à 4, dans lequel, les premières informations comprennent en outre des éléments pour établir une preuve que l'utilisateur est titulaire du moyen d'identification.
  6. 6. Procédé selon l'une quelconque des revendications 1 à 5, dans lequel les premières informations sont filtrées, selon des règles contrôlées par l'utilisateur.
  7. 7. Procédé selon la revendication 1, dans lequel un nouveau moyen d'identification est associé à un utilisateur par la plate-forme, sur demande du système transactionnel.
  8. 8. Procédé selon la revendication 7, dans lequel la plate-forme met à disposition une liste de fonctionnalités, associées au nouveau moyen d'identification, lesdites fonctionnalités étant mises à disposition par le système transactionnel.
  9. 9. Plateforme, adaptée à être couplée à un système transactionnel (24 ; 28, 34), ledit système transactionnel étant adapté à réaliser une transaction entre un utilisateur titulaire d'un moyen d'identification et un tiers, caractérisée en ce que la plateforme comporte : o des moyens d'authentifier l'utilisateur ; o des moyens de générer des premières informations relatives à l'utilisation du moyen d'identification, les premières informations comprenant des éléments pour établir une preuve que l'utilisateur a donné son consentement à l'utilisation du moyen d'identification pour la transaction.
  10. 10. Plateforme selon la revendication 9, dans laquelle, les premières informations comprennent des informations signées avec une clé privée permettant d'authentifier la plate-forme,
  11. 11. Plateforme selon la revendication 9 ou 10, comportant en outre : o des moyens de sélection, par l'utilisateur authentifié, du moyen d'identification parmi un ensemble (L) de moyens d'identification associés à l'utilisateur, o des moyens d'établissement d'une preuve que l'ensemble est propre à l'utilisateur authentifié, à partir des premières informations.
  12. 12. Plateforme selon la revendication 11, comportant en outre des moyens de déclaration par l'utilisateur authentifié d'un nouveau moyen d'identification non compris dans l'ensemble de moyens d'identification associés à l'utilisateur.
  13. 13. Plateforme selon la revendication 9, comportant en outre un moyen d'association d'un nouveau moyen d'identification à un utilisateur par la plate-forme, sur demande du système transactionnel.
  14. 14. Programme d'ordinateur comportant des instructions pour mettre en oeuvre le procédé selon l'une quelconque des revendications 1 à 8 lorsque le programme est exécuté par un ordinateur.
  15. 15. Support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur selon la revendication 14.
FR1056702A 2010-08-20 2010-08-20 Systeme de paiement en ligne Pending FR2963975A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR1056702A FR2963975A1 (fr) 2010-08-20 2010-08-20 Systeme de paiement en ligne

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1056702A FR2963975A1 (fr) 2010-08-20 2010-08-20 Systeme de paiement en ligne

Publications (1)

Publication Number Publication Date
FR2963975A1 true FR2963975A1 (fr) 2012-02-24

Family

ID=43033350

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1056702A Pending FR2963975A1 (fr) 2010-08-20 2010-08-20 Systeme de paiement en ligne

Country Status (1)

Country Link
FR (1) FR2963975A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2799078A1 (fr) * 1999-09-27 2001-03-30 Jacky Montiel Ensemble de protocoles permettant l'authentification rapide pour des systemes transactionnels de commerce d'informations et de services sur internet
US20040177047A1 (en) * 2000-04-17 2004-09-09 Graves Michael E. Authenticated payment
FR2867293A1 (fr) * 2004-03-03 2005-09-09 Biz N Cash Procede et systeme de micropaiement
US20080103972A1 (en) * 2006-10-25 2008-05-01 Payfont Limited Secure authentication and payment system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2799078A1 (fr) * 1999-09-27 2001-03-30 Jacky Montiel Ensemble de protocoles permettant l'authentification rapide pour des systemes transactionnels de commerce d'informations et de services sur internet
US20040177047A1 (en) * 2000-04-17 2004-09-09 Graves Michael E. Authenticated payment
FR2867293A1 (fr) * 2004-03-03 2005-09-09 Biz N Cash Procede et systeme de micropaiement
US20080103972A1 (en) * 2006-10-25 2008-05-01 Payfont Limited Secure authentication and payment system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
PAYS P ET AL: "An intermediation and payment system technology", COMPUTER NETWORKS AND ISDN SYSTEMS, NORTH HOLLAND PUBLISHING. AMSTERDAM, NL, vol. 28, no. 11, 1 May 1996 (1996-05-01), pages 1197 - 1206, XP004018220, ISSN: 0169-7552, DOI: DOI:10.1016/0169-7552(96)00076-1 *

Similar Documents

Publication Publication Date Title
EP3113099B1 (fr) Conteneur de paiement, procédé de création, procédé de traitement, dispositifs et programmes correspondants
CA2971635C (fr) Procede de traitement d'une transaction a partir d'un terminal de communication
KR20180081746A (ko) 보안 트랜잭션 인터페이스
EP3189414A2 (fr) Système de vérification pour transmission sécurisée dans un réseau de traitement distribué
WO2015023172A2 (fr) Systemes et procedes de paiement mobile interpersonnel instantane (p2p)
EP3163487B1 (fr) Procédé de sécurisation de traitement de données transactionnelles, terminal et programme d'ordinateur correspondant
EP3039628A2 (fr) Procede de traitement de donnees transactionnelles, dispositifs et programmes d'ordinateur corrrespondants
EP3485451B1 (fr) Procédé de traitement d'au moins une donnée de moyen de paiement, terminal de paiement et programme d'ordinateur correspondant
FR3080934A1 (fr) Procede et systeme pour effectuer un echange de donnees securise
EP3167420B1 (fr) Procédé de gestion d'une transaction, serveur, produit programme d'ordinateur et medium de stockage correspondants
EP2824625B1 (fr) Méthode de réalisation de transaction, terminal et programme d'ordinateur correspondant
FR2750273A1 (fr) Procede de rechargement de cartes prepayees virtuelles
EP2724305B1 (fr) Procede de transaction dematerialisee
FR2963975A1 (fr) Systeme de paiement en ligne
WO2020128240A1 (fr) Traitement d'un service de tickets electroniques
CA2946145C (fr) Procedes de traitement de donnees transactionnelles, dispositifs et programmes correspondants
FR3011111A1 (fr) Securisation d'une transmission de donnees d'identification
EP4016427A1 (fr) Procede pour la creation d'un instrument de paiement au profit d'un tiers beneficiaire
WO2022254002A1 (fr) Procédé de traitement d'une transaction, dispositif et programme correspondant.
FR3115625A1 (fr) Transactions sans présence de la carte avec une valeur de vérification de carte choisie par le titulaire de la carte
EP3300012A1 (fr) Procede et systeme pour gerer des autorisations d'achat
EP3371760A1 (fr) Procédé de verification d'identité lors d'une virtualisation
EP3223219A1 (fr) Procédé de transfert de transaction, procédé de transaction et terminal mettant en oeuvre au moins l'un d'eux
FR3008516A1 (fr) Methode de realisation de transaction, terminal et programme d'ordinateur correspondant.
FR2808144A1 (fr) Procede et systeme de paiement electronique

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 6

PLFP Fee payment

Year of fee payment: 7

PLFP Fee payment

Year of fee payment: 8

PLFP Fee payment

Year of fee payment: 9

PLFP Fee payment

Year of fee payment: 10

PLFP Fee payment

Year of fee payment: 11

PLFP Fee payment

Year of fee payment: 12

PLFP Fee payment

Year of fee payment: 13

PLFP Fee payment

Year of fee payment: 14