EP1362333A1 - 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

Info

Publication number
EP1362333A1
EP1362333A1 EP02704861A EP02704861A EP1362333A1 EP 1362333 A1 EP1362333 A1 EP 1362333A1 EP 02704861 A EP02704861 A EP 02704861A EP 02704861 A EP02704861 A EP 02704861A EP 1362333 A1 EP1362333 A1 EP 1362333A1
Authority
EP
European Patent Office
Prior art keywords
transaction
securing
payment card
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.)
Withdrawn
Application number
EP02704861A
Other languages
German (de)
English (en)
Inventor
Stéphane 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
Publication of EP1362333A1 publication Critical patent/EP1362333A1/fr
Withdrawn 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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

Definitions

  • the present invention relates to a method and a system for securing a transaction between a merchant and a customer carrying a payment card.
  • the invention finds a particularly advantageous application in the field of securing “distance selling” type transactions carried out by means of a payment card. It also applies to transactions using a magnetic stripe on the said payment card.
  • payment cards include, on the one hand, a visual integrating information on the holder, in particular his name, as well as identification data specific to each payment card, namely his number. identification and its expiry date, and, on the other hand, a magnetic strip on which the same identification data are recorded.
  • Payment cards of this type can be published by groups of commercial brands, by financing organizations or by banking establishments most often grouped into networks.
  • the body of the card may include an electronic component, sometimes called a "chip", which contains not only all the information and data relating to the card and its holder, but also means, microprocessor and associated software, capable of performing complex authentication operations, encryption for example.
  • distance selling To carry out a financial transaction with a payment card, one can use the only data specific to said card contained in the visual mentioned above. This procedure is frequent in France in transactions known as "distance selling".
  • distance selling When said distance selling is carried out on a communication network such as the Internet, the customer carrying the payment card must manually enter the identification number and expiration date of his card on the keyboard of his personal computer.
  • the customer In the particular case of Mail order sales, the customer enters this same data on a paper form which he then sends to the merchant by post.
  • the merchant then transmits the identification data of the card to a management organization accompanied by a request for authorization of the transaction.
  • the management body carries out a certain number of checks concerning the card and the holder and authorizes or not the transaction. You can also carry out a transaction using a payment card using the identification data present in the magnetic strip of the card. This procedure is now relatively little practiced in local shops except in the case of private networks managed in particular by groups of commercial brands.
  • the merchant has a magnetic stripe reader which records the data of the transaction and transmits it to a network management body to which the card belongs. If an authorization is given by the management body, a slip printed by the reader must be signed by the card holder before the transaction can be carried out.
  • the technical problem to be solved by the object of the present invention is to propose a method of securing a transaction between a merchant and a customer carrying a payment card, said transaction involving an authorization request from identification data specific to said payment card, a process which would increase the security of transactions for which knowledge of the card's only identification data is sufficient to obtain authorization.
  • the solution to the technical problem posed consists, according to the present invention, in that the transaction is authorized after verification in a complementary decision module (41) of at least one control criterion determined from at least one parameter specific to said transaction, said control criterion being decided by said bearer (20).
  • a system for securing a transaction between a merchant and a customer carrying a payment card comprising at least one management body capable of authorizing said transaction on the basis of identification data specific to said card.
  • said system also includes an additional decision-making module capable of authorizing the transaction after verification of at least one control criterion determined by said holder on the basis of at least one parameter specific to said transaction.
  • the method of the invention independently adds a complementary control which has the particularity, on the one hand, of being decided by the bearer itself, and, on the other hand, depend on parameters related to the transaction itself.
  • said transaction-specific parameter is chosen from the following list, separately or in combination: existence of the transaction during a given period, number of transactions over a given fixed or sliding period, amount of the transaction in unit or cumulative value, currency of the transaction, identity of the merchant.
  • the invention also provides a filtering process according to which said verification is carried out for a transaction of at least one given type.
  • This arrangement is reflected in the system of the invention in that it further comprises a filtering module capable of subjecting said module additional business intelligence request for verification for a transaction of at least one given type.
  • control criterion can be modified by the holder of the payment card.
  • security system object of the invention, must be adapted so that it further comprises a configuration interface module intended for the modification by the payment card holder of said criterion. control.
  • FIG. 1 is a block diagram of a security system according to the invention.
  • FIG. 1 shows a system for securing a transaction between a merchant 10 and a customer 20 carrying a payment card, a bank card, for example, issued by a management organization 30, also called a network, specialized in the distribution and processing of such cards.
  • a bank card for example, issued by a management organization 30, also called a network, specialized in the distribution and processing of such cards.
  • a management organization 30 also called a network
  • the customer 20 After having made his choice in the catalog which is presented to him on the screen of his personal computer, the customer 20 must provide (1) to the merchant 10 identification data specific to his payment card, namely for example his number and its expiration date. From this data, and other information related to the context of the purchase itself, the merchant 10 addresses (2) to the authorization center 11 of his banking institution a request for authorization of the transaction. This request is transmitted (3) to the network 30 of bank cards which performs a a certain number of checks concerning said card identification data, number and date of validity, as well as, for example, the presence of the card on a red list of cards struck with prohibition. To complete the verification process, the network 30 of bank cards consults (4) the authorization center 21 of the bearer's banking institution 20 so as to implement internal controls, such as the account balance statement of the wearer 20.
  • the security method of the invention adds another authorization condition consisting of a complementary operation of verifying at least one control criterion determined by said holder. from at least one parameter specific to said transaction.
  • the transaction securing system of FIG. 1 comprises a complementary decision-making module 41 capable of carrying out said complementary verification operation and of authorizing the transaction in the event of positive verification.
  • the holder 20 can decide to systematically refuse such or such requests for authorization of financial transactions according to criteria which he will have defined himself.
  • the complementary decision-making module 41 consulted (5) by the holder's authorization center 21, will send back (6) a negative response to the acceptance of the transaction.
  • This prohibition to carry out the transaction will then be transmitted (7, 8) to the merchant's authorization center 11 via the network 30. Consequently, the merchant 10, informed (9) by his authorization center 11, will refuse (10) the sale to bearer 20 since the request for authorization of the transaction is a failure.
  • the bearer 20 has perfect control over the authorization process: it is he and he alone who can positively lead to a request for authorization of a financial transaction.
  • the control criteria determined by the carrier 20 and used by the complementary decision-making module 41 can be very varied in nature. As examples, some possible criteria will now be presented, whether taken separately or in combination.
  • a first basic criterion has as parameter the existence of the transaction itself, namely that the bearer 20 has the possibility of prohibiting or authorize all financial transactions resulting from processing according to the distance selling procedure.
  • this criterion can vary over time, the bearer 20 making a remote purchase being able to temporarily authorize for a given period, one hour for example, all transactions carried out according to this procedure.
  • this same criterion can also be considered by the complementary decision-making module 41 as a default criterion: in the absence of any intention expressed by the holder 20 in this regard, the module 41 blocks all the authorization requests which it are presented.
  • a second control criterion is linked to the parameter represented by the number of transactions processed over a given period, fixed or rolling, defined by the holder 20.
  • a third criterion is configured on the amount of the transaction, whether in unit value or in cumulative value over a fixed or rolling period of time. More specifically, when the transaction exceeds a maximum amount set by the holder 20, the authorization of the financial transaction is refused. Likewise, when the total number of transactions carried out over a given period reaches a ceiling set by the holder 20, any new transaction presented is not authorized. This criterion can be treated globally or by merchant.
  • a fourth control criterion brings into play the parameter constituted by the currency of the transaction.
  • a holder 20 may authorize only financial transactions denominated in francs or pounds, the other emission currencies causing a negative response to the authorization request.
  • a fifth criterion is based on the parameter defined by the identity of the merchant 10. According to this criterion, a holder 20 may only accept requests for authorization of financial transactions from a merchant 10 or a group of merchants, identified by their name or by their type of activity. During a purchase by distance selling, it is then possible, by making available a directory of merchants including their bank numbers, to select the acceptance of requests for authorization of transactions from these merchants only.
  • a filtering module 42 whose role is to submit to the complementary decision-making module 41 the requests for verification of the control criteria corresponding to transactions of one or more types 5 given.
  • these will be distance selling transactions on the Internet, as they could just as easily be distance selling transactions on paper form, or transactions using the magnetic stripe of cards of payment, these transactions having an insufficient level of security which justifies a process
  • This filtering module 42 is therefore to direct authorization requests from, for example, distance selling, to the complementary decision-making module 41. It is integrated into the processing chain of the authorization center 21 of the bearer's banking establishment 20, which
  • a configuration module 43 serving as an interface between the bearer 20 and the complementary decision-making module 41.
  • This configuration interface module 43 can take various forms:
  • the wearer 20 accesses via his personal computer, his mobile phone or his Minitel terminal, a menu allowing him to securely, by identifier and password, configure the module 41 according to the control criteria of his choice, with the possibility to be able to possibly combine them.
  • the configuration services of the complementary decision-making module 41 can also be accessible via a voice server.
  • the configuration thus carried out will be more coarse, in particular as regards the combinations of criteria, than with a Web server for example, with regard to the quality of the human-machine interface seen from the carrier 20.

Landscapes

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

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ée par ledit porteur (20) à partir d'au moins un paramètre propre à ladite transaction. Application aux transactions du type 'vente à distance'.

Description

PROCEDE ET DISPOSITIF DE SECURISATION D'UNE TRANSACTION ENTRE UN COMMERÇANT ET UN CLIENT PORTEUR D'UNE CARTE DE
PAIEMENT
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 œuvre 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 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 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 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 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,
- 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 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 l'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 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.
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 dans un module décisionnel complémentaire (41 ) d'au moins un critère de contrôle déterminé à partir d'au moins un paramètre propre à ladite transaction, ledit critère de contrôle étant décidé par ledit porteur (20).
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 : 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.
Il 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é.
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 œuvre 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 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 œuvre 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, 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 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 œuvre 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 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 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 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 critères de contrôle correspondant à des transactions d'un ou plusieurs types 5 donnés. Dans l'exemple choisi, il s'agira de transactions de vente à distance sur l'Internet, comme elles peuvent tout aussi bien être des transactions de vente à distance sur formulaire papier, ou encore des transactions mettant en œuvre la piste magnétique des cartes de paiement, ces transactions présentant un niveau de sécurisation insuffisant qui justifie un processus
10. 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
15 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 filtrage. Ceci a pour effet de limiter les demandes de vérification auprès du module 41 .
20 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 :
25 - 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.
30 - 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 homme- 5 machine vue du porteur 20.

Claims

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 dans un module décisionnel complémentaire (41 ) d'au moins un critère de contrôle déterminé à partir d'au moins un paramètre propre à ladite transaction, ledit critère de contrôle étant décidé par ledit porteur (20).
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. Procédé de sécurisation selon la revendication 2, caractérisé en ce que ladite transaction est du type mettant en œuvre le réseau Internet.
4. Procédé de sécurisation selon la revendication 2, caractérisé en ce que ladite transaction est du type mettant en œuvre un formulaire papier.
5. Procédé de sécurisation selon la revendication 2, caractérisé en ce que ladite transaction est du type mettant en œuvre une piste magnétique de ladite carte de paiement.
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. 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. 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.
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
5 module décisionnel complémentaire (41 ) une demande de vérification pour une transaction d'au moins un type donné.
10. Système de sécurisation selon la revendication 9, caractérisé en ce que ladite transaction est du type mettant en œuvre le réseau Internet.
11. Système de sécurisation selon la revendication 9, caractérisé en ce 10 que ladite transaction est du type mettant en œuvre un formulaire papier.
12. Système de sécurisation selon la revendication 9, caractérisé en ce que ladite transaction est du type mettant en œuvre une piste magnétique de ladite carte de paiement.
13. Système de sécurisation selon l'une quelconque des revendications 15 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. 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
20 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. Module décisionnel complémentaire (41) pour un système de 25. 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 30 propre à ladite transaction.
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é.
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.
EP02704861A 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 Withdrawn EP1362333A1 (fr)

Applications Claiming Priority (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
FR0102528 2001-02-23
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

Publications (1)

Publication Number Publication Date
EP1362333A1 true EP1362333A1 (fr) 2003-11-19

Family

ID=8860400

Family Applications (1)

Application Number Title Priority Date Filing Date
EP02704861A Withdrawn 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

Country Status (3)

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

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5897621A (en) * 1996-06-14 1999-04-27 Cybercash, Inc. System and method for multi-currency transactions
DE19750849C2 (de) * 1997-11-17 1999-11-11 Deutsche Telekom Ag Verfahren zur Sicherung einer elektronischen Geldbörse gegen übermäßige Benutzung
KR20010102261A (ko) * 1999-02-18 2001-11-15 추후제출 신용카드 시스템 및 방법
JP2001043274A (ja) * 1999-08-03 2001-02-16 Fujitsu Ltd 決済システム及びカード

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO02069283A1 *

Also Published As

Publication number Publication date
WO2002069283A1 (fr) 2002-09-06
FR2821506A1 (fr) 2002-08-30

Similar Documents

Publication Publication Date Title
KR101137137B1 (ko) 신원 인증 방법
EP1014317B1 (fr) Procédé de paiement sécurisé
EP0818763B1 (fr) Procédé de contrôle de transactions sécurisées independantes utilisant un dispositif physique unique
EP3113099A1 (fr) Conteneur de paiement, procédé de création, procédé de traitement, dispositifs et programmes correspondants
EP1153376A1 (fr) Procede de telepaiement et systeme pour la mise en oeuvre de ce procede
EP3039628A2 (fr) Procede de traitement de donnees transactionnelles, dispositifs et programmes d'ordinateur corrrespondants
EP1754205A1 (fr) Procede de paiement anonyme et securise sur internet et mobiles
FR2810433A1 (fr) Systeme et procede de couponnage electronique
EP1323140B1 (fr) Procede pour fournir des donnees d'identification d'une carte de paiement a un usager
FR2750273A1 (fr) Procede de rechargement de cartes prepayees virtuelles
EP1362333A1 (fr) Procede et dispositif de securisation d'une transaction entre un commercant et un client porteur d'une carte de paiement
EP1978479A1 (fr) Cryptogramme dynamique
FR3124299A1 (fr) procédé et dispositif de transmission d’un identifiant d’un utilisateur lors d’un paiement électronique réalisé par l’utilisateur.
WO2003007251A1 (fr) Procede assurant une garantie de paiement pour le commerce electronique notamment par telephone mobile et systeme de mise en oeuvre
WO2002056216A1 (fr) Procede utilisant les cartes de paiement electroniques pour securiser les transactions
CA2325895C (fr) Procede de paiement securise
BHATIA TO STUDY DATA OF E-BANKING OPERATIONS AT KOTAK MAHINDRA BANK
WO2024256700A1 (fr) Procédé de paiement électronique
EP0831434A1 (fr) Procédé de fermeture, notamment de mise en opposition, d'une pluralité de services, et serveur de fermeture, terminal d'acceptation et dispositifs portatifs associés
WO2002046984A1 (fr) Procede securise de transaction entre un acheteur et un vendeur
WO2008084279A1 (fr) Systeme de paiement hautement securise
FR3115625A1 (fr) Transactions sans présence de la carte avec une valeur de vérification de carte choisie par le titulaire de la carte
EP1371036A2 (fr) Systeme et methode de renouvellement de donnees d'identification sur un dispositif de transaction portatif
FR2837952A1 (fr) Procede de paiement en ligne
WO2002052517A1 (fr) Procede et systeme de paiement et equipements de telecommunications mis en oeuvre dans ce systeme

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20030606

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

RIN1 Information on inventor provided before grant (corrected)

Inventor name: MAGLIULO, PHILIPPE

Inventor name: HANNECART, ERIC

Inventor name: PETIT, STEPHANE

17Q First examination report despatched

Effective date: 20090910

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20100323