FR2821506A1 - Procede et dispositif de securisation d'une transaction entre un commercant et un client porteur d'une carte de paiement - Google Patents

Procede et dispositif de securisation d'une transaction entre un commercant et un client porteur d'une carte de paiement Download PDF

Info

Publication number
FR2821506A1
FR2821506A1 FR0102528A FR0102528A FR2821506A1 FR 2821506 A1 FR2821506 A1 FR 2821506A1 FR 0102528 A FR0102528 A FR 0102528A FR 0102528 A FR0102528 A FR 0102528A FR 2821506 A1 FR2821506 A1 FR 2821506A1
Authority
FR
France
Prior art keywords
transaction
payment card
securing
module
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
FR0102528A
Other languages
English (en)
Inventor
Stephane Petit
Eric Hannecart
Philippe Magliulo
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.)
Orange SA
Original Assignee
France Telecom 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 France Telecom SA filed Critical France Telecom SA
Priority to FR0102528A priority Critical patent/FR2821506A1/fr
Priority to PCT/FR2002/000622 priority patent/WO2002069283A1/fr
Priority to EP02704861A priority patent/EP1362333A1/fr
Publication of FR2821506A1 publication Critical patent/FR2821506A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, 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
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, 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
    • G06Q20/403—Solvency checks
    • G06Q20/4037—Remote solvency checks

Abstract

Système de sécurisation d'une transaction entre un commerçant (10) et un client (20) porteur d'une carte de paiement, ledit système comprenant au moins un organisme de gestion (11, 30, 21) apte à autoriser ladite transaction à partir de données d'identification propres à ladite carte de paiement.Selon l'invention, ledit système comprend également un module décisionnel complémentaire (41) apte à autoriser la transaction après vérification d'au moins un critère de contrôle déterminé par ledit porteur (20) à partir d'au moins un paramètre propre à ladite transaction.Application aux transactions du type " vente à distance ".

Description

<Desc/Clms Page number 1>
La présente invention concerne un procédé et un système de sécurisation d'une transaction entre un commerçant et un client porteur d'une carte de paiement.
L'invention trouve une application particulièrement avantageuse dans le domaine de la sécurisation des transactions du type vente à distance effectuées au moyen d'une carte de paiement. Elle s'applique également aux transactions mettant en oeuvre une piste magnétique de ladite carte de paiement.
D'une manière générale, les cartes de paiement comportent, d'une part, un visuel intégrant des informations sur le porteur, notamment son nom, ainsi que des données d'identification propres à chaque carte de paiement, à savoir son numéro d'identification et sa date d'expiration, et, d'autre part, une piste magnétique sur laquelle sont enregistrées les mêmes données d'identification.
Des cartes de paiement de ce type peuvent être éditées par des
Figure img00010001

groupements d'enseignes commerciales, par des organismes de financement ou par des établissements bancaires le plus souvent regroupés en réseaux. Il faut signaler que dans le cas des cartes dites bancaires, le corps de la carte peut comporter un composant électronique, parfois appelé puce , qui contient non seulement toutes les informations et données relatives à la carte et son porteur mais aussi des moyens, microprocesseur et logiciels associés, aptes à effectuer des opérations complexes d'authentification, chiffrement par exemple.
Pour réaliser une transaction financière avec une carte de paiement, on peut utiliser les seules données propres à ladite carte contenues dans le visuel mentionné plus haut. Cette procédure est fréquente en France dans les transactions connues sous le nom de vente à distance . Lorsque ladite vente à distance est réalisée sur un réseau de communication comme l'Internet, le client porteur de la carte de paiement doit introduire manuellement sur le clavier de son ordinateur personnel le numéro d'identification et la date d'expiration de sa carte. Dans le cas particulier de la
<Desc/Clms Page number 2>
vente par correspondance, le client inscrit ces mêmes données sur un formulaire papier qu'il envoie ensuite au commerçant par courrier.
Le commerçant transmet alors les données d'identification de la carte à un organisme de gestion accompagnées d'une demande d'autorisation de la transaction. L'organisme de gestion procède à un certain nombre de
Figure img00020001

vérifications concernant la carte et le porteur et autorise ou non la transaction.
On peut également effectuer une transaction au moyen d'une carte de paiement en utilisant les données d'identification présentes dans la piste
Figure img00020002

magnétique de la carte. Cette procédure est maintenant relativement peu pratiquée en France dans le commerce de proximité sauf dans le cas de réseaux privatifs gérés en particulier par des groupements d'enseignes commerciales. Pour réaliser une telle transaction, le commerçant dispose d'un lecteur de pistes magnétiques qui enregistre les données de la transaction et les transmet à un organisme de gestion du réseau auquel appartient la carte.
Si une autorisation est donnée par l'organisme de gestion, un bordereau imprimé par le lecteur doit être signée par le porteur de la carte pour que la transaction puisse être effectuée.
Cependant, de telles cartes de paiement sont facilement duplicables, physiquement ou en récupérant les données d'identification, et fraudables.
Les importants taux de fraude dans le monde bancaire proviennent de cette source.
De façon à remédier à cette situation, il a été décidé d'ajouter un code confidentiel aux données d'identification de la carte, ce code n'étant connu que du seul porteur de la carte, et, surtout, de sécuriser les échanges d'informations par l'utilisation des cartes à puce. Il est alors possible : - d'authentifier à chaque transaction le porteur de la carte par présentation et vérification locale du code confidentiel,
Figure img00020003

- et, ensuite, générer des preuves (certificats) sur l'acte d'achat à l'aide des secrets personnalisés que la carte contient.
Toutefois, si, dans certains pays, les terminaux de traitement des cartes de paiement à puce se sont fortement déployés dans le commerce de proximité, cette procédure étant la seule à apporter par contrat la garantie de paiement au commerçant, ce n'est pas le cas aujourd'hui dans le domaine du commerce à distance. Pour ce faire, il faudrait, en effet, généraliser chez les particuliers l'usage de lecteurs de carte pouvant effectuer des transactions
<Desc/Clms Page number 3>
financières dans des conditions raisonnables de sécurité. Or, actuellement, l'échec de la diffusion dans le public des lecteurs de carte sécurisés branchés sur un ordinateur personnel pour commercer sur l'Internet démontre la difficulté d'une telle généralisation. Une autre solution fondée sur l'utilisation d'un terminal mobile bi-fente existe également mais se heurte de la même manière aux difficultés liées à un déploiement à grande échelle.
Il existe aujourd'hui des sociétés qui fournissent à leurs clients des moyens permettant de sécuriser l'emploi de cartes de paiement sans puce dans le contexte de Internet. Ces moyens consistent essentiellement à éviter la circulation en ligne du numéro de la carte. On citera par exemple : - les plates-formes de commerce électronique qui proposent aux porteurs d'inscrire définitivement leur numéro de carte de paiement sur leur serveur et d'utiliser un pseudonyme (identifiant, mot de passe assorti parfois d'un questionnaire) pour accéder à la ressource.
- les systèmes qui substituent au numéro réel de la carte de paiement un numéro temporaire parfaitement formé. Ce numéro, collecté auprès d'un centre d'autorisation spécialisé, est utilisé par le porteur pour effectuer un achat chez un commerçant, transite sur le serveur du commerçant où il apparaît comme un véritable numéro de carte de paiement, et remonte vers un centre d'autorisation dédié qui traite alors la transaction en substituant au
Figure img00030001

numéro temporaire le vrai numéro de la carte et en renvoyant la transaction vers le centre d'autorisation de l'organisme financier du porteur.
Dans tous les cas, ces procédures contournent effectivement le problème de l'interception en ligne des données de la carte, mais ne peuvent résoudre le problème de leur obtention frauduleuse par d'autres circuits et de leur utilisation en ligne.
Aussi, le problème technique à résoudre par l'objet de la présente invention est de proposer un procédé de sécurisation d'une transaction entre un commerçant et un client porteur d'une carte de paiement, ladite transaction impliquant une demande d'autorisation à partir de données d'identification propres à ladite carte de paiement, procédé qui permettrait d'augmenter la sécurité des transactions pour lesquelles la connaissance des seules données d'identification de la carte suffisent pour en obtenir l'autorisation.
Figure img00030002
La solution au problème technique posé consiste, selon la présente invention, en ce que la transaction est autorisée après vérification d'au moins
<Desc/Clms Page number 4>
un critère de contrôle déterminé par ledit porteur à partir d'au moins un paramètre propre à ladite transaction.
De même, un système de sécurisation d'une transaction entre un commerçant et un client porteur d'une carte de paiement, ledit système comprenant au moins un organisme de gestion apte à autoriser ladite transaction à partir de données d'identification propres à ladite carte de paiement, est, selon l'invention, notamment remarquable en ce que ledit système comprend également un module décisionnel complémentaire apte à autoriser la transaction après vérification d'au moins un critère de contrôle déterminé par ledit porteur à partir d'au moins un paramètre propre à ladite transaction.
Ainsi, à la demande d'autorisation usuelle mettant en jeu les données d'identification de la carte, le procédé de l'invention ajoute de manière indépendante un contrôle complémentaire qui présente la particularité, d'une part, d'être décidé par le porteur lui-même, et, d'autre part, de dépendre de paramètres liés à la transaction elle-même. Il en résulte une sécurisation très forte du fait que lesdits critères de contrôle ne circulent pas en ligne et sont difficilement accessibles aux fraudeurs.
Selon un mode de réalisation de l'invention, ledit paramètre propre à la transaction est choisi dans la liste suivante, séparément ou en combinaison :
Figure img00040001

existence de la transaction pendant une période donnée, nombre de transactions sur une période donnée fixe ou glissante, montant de la transaction en valeur unitaire ou cumulée, monnaie de la transaction, identité du commerçant.
Par existence de la transaction pendant une période donnée, on entend la possibilité pour le porteur de décider d'autoriser ou non toute transaction, quelle qu'elle soit, pendant la période donnée choisie. La sécurisation apportée par l'invention peut donc être complète, il suffit pour cela au porteur d'interdire toute transaction purement et simplement.
N est également prévu par l'invention un processus de filtrage selon lequel ladite vérification est effectuée pour une transaction d'au moins un type donné. Cette disposition se traduit au niveau du système de l'invention en ce qu'il comprend en outre un module de filtrage apte à soumettre audit module décisionnel complémentaire une demande de vérification pour une transaction d'au moins un type donné.
<Desc/Clms Page number 5>
A titre d'exemple, on peut envisager de ne pas soumettre au contrôle complémentaire des transactions dont on estime qu'elles sont suffisamment sécurisées, comme celles contenant un certificat carte à mémoire ou indiquant qu'elles ont été effectuées avec une carte de paiement à puce. Le procédé de sécurisation de l'invention n'est alors utilisé que si ladite transaction est du type vente à distance, réalisée sur l'Internet ou sur formulaire papier, ou également dans le cas où ladite transaction est du type mettant en oeuvre une piste magnétique de ladite carte de paiement.
Enfin, l'invention prévoit que ledit critère de contrôle est modifiable par le porteur de la carte de paiement. A cet effet, le système de sécurisation, objet de l'invention, doit être adapté de manière à ce qu'il comprend en outre un module d'interface de configuration destiné à la modification par le porteur de la carte de paiement dudit critère de contrôle.
La description qui va suivre en regard du dessin annexé, donné à titre d'exemple non limitatif, fera bien comprendre en quoi consiste l'invention et comment elle peut être réalisée.
La figure 1 est un schéma synoptique d'un système de sécurisation conforme à l'invention.
Sur la figure 1 est représenté un système de sécurisation d'une transaction entre un commerçant 10 et un client 20 porteur d'une carte de paiement, une carte bancaire, par exemple, éditée par un organisme 30 de
Figure img00050001

gestion, appelé aussi réseau, spécialisé dans la diffusion et le traitement de telles cartes. Pour illustrer le procédé de sécurisation mis en oeuvre par le système de la figure 1, on supposera que ladite transaction est du type vente à distance sur l'Internet.
Après avoir fait son choix dans le catalogue qui lui est présenté sur l'écran de son ordinateur personnel, le client 20 doit fournir (1) au commerçant 10 des données d'identification propres à sa carte de paiement, à savoir par exemple son numéro d'identification et sa date d'expiration. A partir de ces données, et d'autres informations liées au contexte de l'achat proprement dit,
Figure img00050002

le commerçant 10 adresse (2) au centre 11 d'autorisation de son institution bancaire une demande d'autorisation de la transaction. Cette demande est transmise (3) au réseau 30 de cartes bancaires qui effectue un certain nombre de vérifications concernant lesdites données d'identification de la carte, numéro et date de validité, ainsi que, par exemple, la présence de la carte sur
<Desc/Clms Page number 6>
une liste rouge de cartes frappées d'interdiction. Pour compléter le processus de vérification, le réseau 30 de cartes bancaires consulte (4) le centre 21 d'autorisation de l'institution bancaire du porteur 20 de manière à mettre en oeuvre des contrôles internes, tels que l'état du solde du compte du porteur 20.
A toutes ces vérifications qui concernent essentiellement les données d'identification de la carte, le procédé de sécurisation de l'invention ajoute une autre condition d'autorisation consistant en une opération complémentaire de vérification d'au moins un critère de contrôle déterminé par ledit porteur à partir d'au moins un paramètre propre à ladite transaction.
A cet effet, le système de sécurisation de transaction de la figure 1 comprend un module décisionnel complémentaire 41 apte à effectuer ladite
Figure img00060001

opération complémentaire de vérification et à autoriser la transaction en cas de vérification positive.
Ainsi, le porteur 20 peut décider de refuser systématiquement telles ou telles demandes d'autorisation de transactions financières en fonction de critères qu'il aura définis lui-même. Dans ce cas, le module décisionnel
Figure img00060002

complémentaire 41, consulté (5) par le centre 21 d'autorisation du porteur, renverra (6) une réponse négative à l'acceptation de la transaction. Cette interdiction d'effectuer la transaction sera alors transmise (7, 8) jusqu'au centre 11 d'autorisation du commerçant via le réseau 30. En conséquence, le commerçant 10, informé (9) par son centre 11 d'autorisation, refusera (10) la vente au porteur 20 puisque la demande d'autorisation de la transaction est un échec.
On comprend que, dans un tel système, le porteur 20 a une parfaite maîtrise sur le processus d'autorisation : c'est lui et lui seul qui peut faire aboutir positivement une demande d'autorisation de transaction financière.
Les critères de contrôle déterminés par le porteur 20 et utilisés par le module décisionnel complémentaire 41 peuvent être de nature très variée. A titre d'exemples, quelques critères possibles vont maintenant être présentés, qu'ils soient pris séparément ou en combinaison.
Un premier critère de base a pour paramètre l'existence de la transaction elle-même, à savoir que le porteur 20 a la possibilité d'interdire ou d'autoriser toutes les transactions financières issues d'un traitement selon la procédure de vente à distance. Bien entendu, ce critère peut varier dans le
<Desc/Clms Page number 7>
temps, le porteur 20 réalisant un achat à distance pouvant autoriser temporairement pendant une période donnée, une heure par exemple, toutes transactions effectuées suivant cette procédure. Par ailleurs, ce même critère peut aussi être considéré par le module décisionnel complémentaire 41 comme un critère par défaut : en l'absence d'intention exprimée par le porteur
20 à cet égard, le module 41 bloque toutes les demandes d'autorisation qui lui sont présentées.
Un second critère de contrôle est lié au paramètre représenté par le nombre de transactions traitées sur une période donnée, fixe ou glissante, définie par le porteur 20. Si, durant la période considérée, ce nombre atteint une valeur maximum, toute transaction demandée ultérieurement est systématiquement refusée.
Un troisième critère est paramétré sur le montant de la transaction, que ce soit en valeur unitaire ou en valeur cumulée sur une période de temps fixe ou glissante. Plus précisément, lorsque la transaction dépasse un montant maximum fixé par le porteur 20, l'autorisation de la transaction financière est refusée. De même, lorsque le cumul des transactions effectuées sur une période donnée atteint un plafond fixé par le porteur 20, toute nouvelle transaction présentée n'est pas autorisée. Ce critère peut être traité globalement ou par commerçant.
Un quatrième critère de contrôle met en jeu le paramètre constitué par la monnaie de la transaction. Ainsi, un porteur 20 pourra n'autoriser que des transactions financières libellées en francs ou en livres, les autres monnaies d'émission provoquant une réponse négative à la demande d'autorisation.
Enfin, un cinquième critère repose sur le paramètre défini par l'identité du commerçant 10. Selon ce critère, un porteur 20 peut n'accepter que les demandes d'autorisation de transactions financières émanant d'un commerçant 10 ou un groupe de commerçants, identifiés par leur nom ou par leur type d'activité. Lors d'un achat par vente à distance, il est alors possible, moyennant la mise à disposition d'un annuaire de commerçants intégrant leurs numéros bancaires, de sélectionner l'acceptation de demandes d'autorisation de transactions provenant de ces seuls commerçants.
On peut observer sur la figure 1 la présence dans la procédure d'autorisation d'un module 42 de filtrage dont le rôle est de soumettre au module décisionnel complémentaire 41 les demandes de vérification des
<Desc/Clms Page number 8>
critères de contrôle correspondant à des transactions d'un ou plusieurs types donnés. Dans l'exemple choisi, il s'agira de transactions de vente à distance sur Internet, comme elles peuvent tout aussi bien être des transactions de vente à distance sur formulaire papier, ou encore des transactions mettant en oeuvre la piste magnétique des cartes de paiement, ces transactions présentant un niveau de sécurisation insuffisant qui justifie un processus d'autorisation particulier.
Ce module 42 de filtrage a donc pour but d'orienter vers le module décisionnel complémentaire 41 les demandes d'autorisation issues, par exemple, d'une vente à distance. Il est intégré à la chaîne de traitement du centre 21 d'autorisation de l'établissement bancaire du porteur 20, lequel procède d'abord à des vérifications qui lui sont propres, tels que l'état du solde du porteur 20, puis fait éventuellement appel au module décisionnel complémentaire 41 si la transaction est d'un type reconnu par le module 42 de
Figure img00080001

filtrage. Ceci a pour effet de limiter les demandes de vérification auprès du module 41.
Afin de permettre au porteur 20 de la carte de paiement de modifier ses critères de contrôle, il est prévu un module 43 de configuration servant d'interface entre le porteur 20 et le module décisionnel complémentaire 41. Ce module 43 d'interface de configuration peut se présenter sous diverses formes : - sous la forme d'un serveur Web, WAP ou Minitel. Le porteur 20 accède via son ordinateur personnel, son téléphone mobile ou son terminal Minitel, à un menu lui permettant de manière sécurisée, par identifiant et mot de passe, de configurer le module 41 selon les critères de contrôle de son choix, avec la possibilité de pouvoir éventuellement les combiner.
- sous la forme d'un serveur vocal. Les services de configuration du module décisionnel complémentaire 41 peuvent également être accessibles via un serveur vocal. Mais il est clair que le paramétrage ainsi réalisé sera plus grossier, notamment au niveau des combinaisons de critères, qu'avec un serveur Web par exemple, au regard de la qualité de l'interface hommemachine vue du porteur 20.

Claims (17)

  1. REVENDICATIONS 1. Procédé de sécurisation d'une transaction entre un commerçant (10) et un client (20) porteur d'une carte de paiement, ladite transaction impliquant une demande d'autorisation à partir de données d'identification propres à ladite carte de paiement, caractérisé en ce que la transaction est autorisée après vérification d'au moins un critère de contrôle déterminé par ledit porteur (20) à partir d'au moins un paramètre propre à ladite transaction.
  2. 2. Procédé de sécurisation selon la revendication 1, caractérisé en ce que ladite vérification est effectuée pour une transaction d'au moins un type donné.
  3. 3. Procédé de sécurisation selon la revendication 2, caractérisé en ce que ladite transaction est du type mettant en oeuvre le réseau Internet.
  4. 4. Procédé de sécurisation selon la revendication 2, caractérisé en ce que ladite transaction est du type mettant en oeuvre un formulaire papier.
    Figure img00090001
  5. 5. Procédé de sécurisation selon la revendication 2, caractérisé en ce que ladite transaction est du type mettant en oeuvre une piste magnétique de ladite carte de paiement.
  6. 6. Procédé de sécurisation selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ledit critère de contrôle est modifiable par le porteur (20) de la carte de paiement.
  7. 7. Procédé de sécurisation selon l'une quelconque des revendications 1 à 6, caractérisé en ce que ledit paramètre propre à la transaction est choisi dans la liste suivante, séparément ou en combinaison : existence de la transaction pendant une période donnée, nombre de transactions sur une période donnée fixe ou glissante, montant de la transaction en valeur unitaire ou cumulée, monnaie de la transaction, identité du commerçant.
  8. 8. Système de sécurisation d'une transaction entre un commerçant (10) et un client (20) porteur d'une carte de paiement, ledit système comprenant au moins un organisme (11,30, 21) de gestion apte à autoriser ladite transaction à partir de données d'identification propres à ladite carte de paiement, caractérisé en ce que ledit système comprend également un module décisionnel complémentaire (41) apte à autoriser la transaction après vérification d'au moins un critère de contrôle déterminé par ledit porteur (20) à partir d'au moins un paramètre propre à ladite transaction.
    <Desc/Clms Page number 10>
  9. 9. Système de sécurisation selon la revendication 8, caractérisé en ce qu'il comprend en outre un module (42) de filtrage apte à soumettre audit module décisionnel complémentaire (41) une demande de vérification pour une transaction d'au moins un type donné.
  10. 10. Système de sécurisation selon la revendication 9, caractérisé en ce que ladite transaction est du type mettant en oeuvre le réseau Internet.
    Figure img00100001
  11. 11. Système de sécurisation selon la revendication 9, caractérisé en ce que ladite transaction est du type mettant en oeuvre un formulaire papier.
  12. 12. Système de sécurisation selon la revendication 9, caractérisé en ce que ladite transaction est du type mettant en oeuvre une piste magnétique de ladite carte de paiement.
  13. 13. Système de sécurisation selon l'une quelconque des revendications 8 à 12, caractérisé en ce qu'il comprend en outre un module (43) d'interface de configuration destiné à la modification par le porteur (20) de la carte de paiement dudit critère de contrôle.
  14. 14. Système de sécurisation selon l'une quelconque des revendications 8 à 13, caractérisé en ce que ledit paramètre propre à la transaction est choisi dans la liste suivante, séparément ou en combinaison : existence de la transaction pendant une période donnée, nombre de transactions sur une période donnée fixe ou glissante, montant de la transaction en valeur unitaire ou cumulée, monnaie de la transaction, identité du commerçant.
  15. 15. Module décisionnel complémentaire (41) pour un système de sécurisation d'une transaction entre un commerçant (10) et un client (20) porteur d'une carte de paiement selon l'une quelconque des revendications 8 à 14, caractérisé en ce que ledit module décisionnel complémentaire (41) est apte à autoriser la transaction après vérification d'au moins un critère de contrôle déterminé par ledit porteur (20) à partir d'au moins un paramètre propre à ladite transaction.
  16. 16. Module (42) de filtrage pour un système de sécurisation d'une transaction entre un commerçant (10) et un client (20) porteur d'une carte de paiement, ledit système comprenant un module décisionnel complémentaire (41) selon la revendication 15, caractérisé en ce que ledit module (42) de filtrage est apte à soumettre audit module décisionnel complémentaire (41) une demande de vérification pour une transaction d'au moins un type donné.
    <Desc/Clms Page number 11>
  17. 17. Module (43) d'interface de configuration pour un système de sécurisation d'une transaction entre un commerçant (10) et un client (20) porteur d'une carte de paiement, ledit système comprenant un module décisionnel complémentaire (41) selon la revendication 15, caractérisé en ce que ledit module (43) d'interface de configuration est destiné à la modification par le porteur (20) de la carte de paiement dudit critère de contrôle.
FR0102528A 2001-02-23 2001-02-23 Procede et dispositif de securisation d'une transaction entre un commercant et un client porteur d'une carte de paiement Pending FR2821506A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
FR0102528A FR2821506A1 (fr) 2001-02-23 2001-02-23 Procede et dispositif de securisation d'une transaction entre un commercant et un client porteur d'une carte de paiement
PCT/FR2002/000622 WO2002069283A1 (fr) 2001-02-23 2002-02-18 Procede et dispositif de securisation d'une transaction entre un commercant et un client porteur d'une carte de paiement
EP02704861A EP1362333A1 (fr) 2001-02-23 2002-02-18 Procede et dispositif de securisation d'une transaction entre un commercant et un client porteur d'une carte de paiement

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0102528A FR2821506A1 (fr) 2001-02-23 2001-02-23 Procede et dispositif de securisation d'une transaction entre un commercant et un client porteur d'une carte de paiement

Publications (1)

Publication Number Publication Date
FR2821506A1 true FR2821506A1 (fr) 2002-08-30

Family

ID=8860400

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0102528A Pending FR2821506A1 (fr) 2001-02-23 2001-02-23 Procede et dispositif de securisation d'une transaction entre un commercant et un client porteur d'une carte de paiement

Country Status (3)

Country Link
EP (1) EP1362333A1 (fr)
FR (1) FR2821506A1 (fr)
WO (1) WO2002069283A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997048078A2 (fr) * 1996-06-14 1997-12-18 Cybercash, Inc. Systeme et procede de transactions a devises multiples
EP0917116A2 (fr) * 1997-11-17 1999-05-19 Deutsche Telekom AG Méthode pour la sécurisation d'un porte-monnaie électronique contre l'usage excessif et porte-monnaie électronique
WO2000049586A1 (fr) * 1999-02-18 2000-08-24 Orbis Patents Limited Systeme et procede de carte de credit
EP1074951A1 (fr) * 1999-08-03 2001-02-07 Fujitsu Limited Système de réglement et carte associée

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997048078A2 (fr) * 1996-06-14 1997-12-18 Cybercash, Inc. Systeme et procede de transactions a devises multiples
EP0917116A2 (fr) * 1997-11-17 1999-05-19 Deutsche Telekom AG Méthode pour la sécurisation d'un porte-monnaie électronique contre l'usage excessif et porte-monnaie électronique
WO2000049586A1 (fr) * 1999-02-18 2000-08-24 Orbis Patents Limited Systeme et procede de carte de credit
EP1074951A1 (fr) * 1999-08-03 2001-02-07 Fujitsu Limited Système de réglement et carte associée

Also Published As

Publication number Publication date
EP1362333A1 (fr) 2003-11-19
WO2002069283A1 (fr) 2002-09-06

Similar Documents

Publication Publication Date Title
KR101137137B1 (ko) 신원 인증 방법
EP1014317B1 (fr) Procédé de paiement sécurisé
EP3113099A1 (fr) Conteneur de paiement, procédé de création, procédé de traitement, dispositifs et programmes correspondants
CA2615295A1 (fr) Methodes et systemes pour des transactions financieres securisees ameliorees fondees sur internet
EP1153376A1 (fr) Procede de telepaiement et systeme pour la mise en oeuvre de ce procede
JPH11232348A (ja) 仮想ウォレットシステム
FR2751104A1 (fr) Procede de controle de transactions securisees independantes utilisant un dispositif physique unique
US20120166339A1 (en) Payment system, purchasing system, and method for performing a plurality of payment processes
EP1110186B1 (fr) Procede de paiement electronique
EP3039628A2 (fr) Procede de traitement de donnees transactionnelles, dispositifs et programmes d&#39;ordinateur corrrespondants
FR2810433A1 (fr) Systeme et procede de couponnage electronique
EP1323140B1 (fr) Procede pour fournir des donnees d&#39;identification d&#39;une carte de paiement a un usager
FR2750273A1 (fr) Procede de rechargement de cartes prepayees virtuelles
FR2821506A1 (fr) Procede et dispositif de securisation d&#39;une transaction entre un commercant et un client porteur d&#39;une carte de paiement
FR2914763A1 (fr) Cryptogramme dynamique
FR2819662A1 (fr) Procede utilisant les cartes de paiement electroniques pour securiser les transactions
CA2325895C (fr) Procede de paiement securise
EP0831434A1 (fr) Procédé de fermeture, notamment de mise en opposition, d&#39;une pluralité de services, et serveur de fermeture, terminal d&#39;acceptation et dispositifs portatifs associés
FR3115625A1 (fr) Transactions sans présence de la carte avec une valeur de vérification de carte choisie par le titulaire de la carte
BHATIA TO STUDY DATA OF E-BANKING OPERATIONS AT KOTAK MAHINDRA BANK
WO2002046984A1 (fr) Procede securise de transaction entre un acheteur et un vendeur
WO2008084279A1 (fr) Systeme de paiement hautement securise
WO2002075674A2 (fr) Systeme et methode de renouvellement de donnees d&#39;identification sur un dispositif de transaction portatif
FR2837952A1 (fr) Procede de paiement en ligne
FR3074946A1 (fr) Methodes et systemes de transaction electronique