FR3115625A1 - Transactions sans présence de la carte avec une valeur de vérification de carte choisie par le titulaire de la carte - Google Patents

Transactions sans présence de la carte avec une valeur de vérification de carte choisie par le titulaire de la carte Download PDF

Info

Publication number
FR3115625A1
FR3115625A1 FR2010850A FR2010850A FR3115625A1 FR 3115625 A1 FR3115625 A1 FR 3115625A1 FR 2010850 A FR2010850 A FR 2010850A FR 2010850 A FR2010850 A FR 2010850A FR 3115625 A1 FR3115625 A1 FR 3115625A1
Authority
FR
France
Prior art keywords
transaction
cvv
cardholder
card
payment
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
FR2010850A
Other languages
English (en)
Inventor
Łukasz Świątek
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.)
Idemia France SAS
Original Assignee
Idemia France SAS
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 Idemia France SAS filed Critical Idemia France SAS
Priority to FR2010850A priority Critical patent/FR3115625A1/fr
Priority to EP21203802.0A priority patent/EP3989152A1/fr
Priority to US17/451,733 priority patent/US20220129901A1/en
Publication of FR3115625A1 publication Critical patent/FR3115625A1/fr
Pending legal-status Critical Current

Links

Classifications

    • 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/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation
    • 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/4018—Transaction verification using the card verification value [CVV] associated with the card
    • 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/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3223—Realising banking transactions through M-devices
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile devices
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile devices
    • G06Q20/3267—In-app payments
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/356—Aspects of software for card payments
    • G06Q20/3567—Software being in the reader
    • 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/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • 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/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • 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/385—Payment protocols; Details thereof using an alias or single-use codes
    • 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/4012—Verifying personal identification numbers [PIN]
    • 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/405—Establishing or using transaction specific rules

Landscapes

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

Abstract

Un titulaire de carte saisit (305), dans un système marchand (20), des informations de paiement et un CVV de transaction choisi librement. Un système de paiement (30) reçoit (400) une demande du marchand, comportant le CVV et des informations de transaction, et envoie (405) une demande d’autorisation à un dispositif du titulaire (13). Les informations de transaction sont affichées (310) sur le dispositif et invitent le titulaire à saisir le CVV comme confirmation. Le titulaire saisit (315) un CVV de confirmation. Le système approuve (240, 415) la transaction lorsque les CVV sont identiques. Le CVV peut avoir une durée de vie courte et être changé à chaque transaction, augmentant la sécurité des transactions. Les contraintes de certification PCI des serveurs sont également réduites. Enfin, le titulaire a plus de contrôle sur la validation de la transaction. Figure pour l’abrégé : Fig.2

Description

Transactions sans présence de la carte avec un CVV choisi par le titulaire de carte
La présente demande concerne les transactions sans présence de la carte.
Les transactions financières basées sur les cartes de paiement, telles que les cartes de crédit et de débit, présentent certains problèmes de sécurité. Afin d’effectuer une transaction par carte en utilisant, par exemple, une carte de crédit, un titulaire de carte d’utilisateur doit fournir un numéro de compte principal (PAN) et une valeur de vérification de carte, appelée Valeur de Vérification de Carte (« Card Verification Value », CVV ou CV2), Code de Vérification de Carte (« Card Verification Code », CVC) ou code de sécurité de carte (« Card Security Code », CSC). Comme décrit dans le présent document, les termes CVV, CVC et CSC peuvent être utilisés de manière interchangeable.
Une valeur de vérification de carte (CVV) est habituellement imprimée au recto ou au verso de la carte de paiement, généralement en caractères lisibles par l’homme. Il peut s’agir d’une valeur à trois chiffres ou à quatre chiffres.
Le CVV est utilisé pour vérifier que le client a la carte en sa possession lorsqu’il effectue la transaction. Il s’agit donc d’une information strictement confidentielle. Par exemple, lorsque la transaction est une transaction "sans présence de la carte" (« card not present » en langue anglo-saxonne), c’est-à-dire lorsque la carte de paiement ne peut pas être glissée ou que sa puce ne peut pas être lue, comme dans le cas d’une transaction en ligne ou par téléphone, le code CVV imprimé peut être saisi au clavier ou fourni oralement pour confirmer que le client qui procède à la transaction est en possession de la carte de paiement, ou, du moins, qu’il a connaissance du code de vérification de carte.
Aujourd’hui, des mécanismes de sécurité supplémentaires ont été mis au point pour sécuriser la transaction. Notamment, la banque du titulaire de carte qui reçoit une demande de transaction depuis un système marchand (ou banque de commerçant) peut demander au titulaire de carte de confirmer la transaction. Cela peut se faire à l’aide d’un dispositif du titulaire de carte disposant d’une application de la banque du titulaire de carte. En réponse à une confirmation du titulaire de carte, la banque du titulaire de carte autorise alors la transaction au système marchand. Ces mécanismes présentent toutefois des inconvénients, comme une complexification du processus de transaction par la mise en œuvre d’une redirection du site web marchand vers le service bancaire pour confirmer la transaction.
Les transactions sans présence de la carte présentent certaines failles de sécurité. Comme le PAN et/ou le CVV sont fournis sous forme de caractères lisibles par l’homme, et sont soit saisis, soit entrés dans un bon de commande imprimé ou faxé, soit fournis oralement, ils ne peuvent généralement pas être protégés cryptographiquement, par exemple, codés. Il est donc facile pour les parties malveillantes de récupérer les informations de carte et de les réutiliser pour des transactions frauduleuses.
Le CVV dynamique a été mis au point pour surmonter une partie de ces failles. Un nouveau CVV est généré dynamiquement à une récurrence temporelle déterminée, sur la base d’une clé maîtresse émetteur. Cette solution n’est cependant pas pleinement satisfaisante car elle nécessite une certification PCI du serveur ou des serveurs en raison de l’utilisation d’une clé maîtresse.
De nouvelles techniques visant à réduire les transactions frauduleuses dans les infrastructures de paiement existantes seraient les bienvenues. De nouvelles techniques visant à donner au titulaire de carte plus de contrôle sur le CVV seraient également les bienvenues. De nouvelles techniques permettant de réduire les contraintes de certification PCI seraient également les bienvenues. Plus généralement, la sécurisation des transactions sans présence de la carte est recherchée.
Pour surmonter certaines des préoccupations susmentionnées, l’inventeur envisage de permettre au titulaire de carte de définir librement son CVV, grâce à un mécanisme de confirmation auquel une personne malveillante n’a pas accès et qui garantit que le titulaire de carte est toujours en possession d’éléments d’accréditation (« credentials » en langue anglo-saxonne) de la carte de paiement (ce qui équivaut à être en possession de la carte de paiement elle-même).
Ainsi, le CVV peut avoir une durée de vie courte et être changé à chaque transaction, ce qui augmente la sécurité des transactions. De même, les contraintes de certification PCI sur le serveur sont réduites puisqu’aucune clé maîtresse émetteur n’est requise pour le CVV. Enfin, le titulaire de carte a plus de contrôle sur la validation de la transaction.
Dans ce contexte, l’invention fournit d’abord un procédé pour effectuer une transaction sans présence de la carte, le procédé comprenant, au niveau d’un système de paiement :
la réception d’une première valeur de vérification de carte, CVV, avec des informations de transaction en provenance d’un système marchand,
la réception, à partir d’un dispositif du titulaire de carte, d’une réponse d’autorisation de transaction qui est basée sur un deuxième CVV. Le dispositif du titulaire de carte est un dispositif personnel du titulaire de carte, donc distinct du système marchand, qui est associé à la carte de paiement utilisée pour la transaction. Notamment, un téléphone intelligent avec une application bancaire ou un portefeuille électronique peut être utilisé, et
l’approbation ou le refus de la transaction sur la base des premier et deuxième CVV. Approuver la transaction est synonyme d’autoriser, de permettre ou de valider la transaction.
Corrélativement, chez le titulaire de carte, un procédé pour effectuer une transaction sans présence de la carte comprend :
l’entrée d’un premier CVV dans un système marchand connecté à un système de paiement, pour initier une transaction,
l’entrée d’une confirmation de transaction par l’utilisateur sur un dispositif du titulaire de carte connecté au système de paiement, la confirmation de transaction par l’utilisateur étant basée sur un deuxième CVV, et
la réception, par le biais du système marchand, d’une approbation ou d’un refus de la transaction en fonction des premier et deuxième CVV.
Par conséquent, lors de la réalisation d’une transaction, un client entre un premier CVV, qu’il peut choisir librement, avec des informations de paiement ou transaction basées sur la carte (par exemple un PAN tokenisé, une date d’expiration, …). Le système de paiement peut demander une autorisation de transaction à l’émetteur de carte, qui est transmise à un dispositif du titulaire de carte. Les informations de transaction peuvent alors être affichées au titulaire de carte, l’invitant à valider ou non la transaction. Le titulaire de carte peut entrer un CVV attendu (le deuxième) sur la base du premier CVV, par exemple le même CVV, pour autoriser la transaction, ou confirmer un CVV affiché, ou sélectionner un CVV parmi des CVV affichés. Le système de paiement qui reçoit une telle réponse à la demande d’autorisation de transaction peut déterminer, sur la base du CVV entré et du CVV de confirmation, s’il faut permettre ou refuser la transaction.
La présente invention fournit également un système de paiement traitant une transaction sans présence de la carte, le système de paiement comprenant :
un serveur de réception des transactions configuré pour recevoir une première valeur de vérification de carte, CVV, avec des informations de transaction provenant d’un système marchand,
un serveur d’autorisation configuré pour recevoir, d’un dispositif du titulaire de carte, une réponse d’autorisation de transaction qui est basée sur un deuxième CVV, et pour approuver ou refuser la transaction sur la base des premier et deuxième CVV.
Corrélativement, un système de titulaire de carte comprend un dispositif d’accès à un système marchand et un dispositif de titulaire de carte connecté à un système de paiement. Le dispositif d’accès peut être un simple navigateur web permettant d’accéder à un site web marchand.
Le dispositif d’accès est configuré pour qu’un titulaire de carte entre un premier CVV dans le système marchand pour initier une transaction.
Le dispositif du titulaire de carte est configuré pour que le titulaire de carte entre une confirmation de transaction par l’utilisateur, la confirmation de transaction par l’utilisateur étant basée sur un deuxième CVV.
Et le dispositif d’accès reçoit, par le biais du système marchand, une approbation ou un refus de la transaction en fonction des premier et deuxième CVV.
Les caractéristiques facultatives des modes de réalisation de l’invention sont définies dans les revendications annexées. Certaines de ces caractéristiques sont expliquées ci-dessous en référence à un procédé, tandis qu’elles peuvent être transposées en caractéristiques de dispositifs.
Dans certains modes de réalisation, le premier CVV est entré par le titulaire de carte dans le système marchand et le deuxième CVV est entré par le titulaire de carte sur le dispositif du titulaire de carte ou est sélectionné par le titulaire de carte depuis une liste de CVV affichés sur le dispositif du titulaire de carte ou est confirmé par le titulaire de carte lorsqu’il est affiché sur le dispositif du titulaire de carte. De préférence, le premier CVV est sélectionné librement par le titulaire de carte, étant entendu que le deuxième CVV doit être une confirmation du premier. La sélection peut être faite dans une plage de valeurs prédéfinie, généralement de [0, 10n-1], où n est le nombre de chiffres du CVV.
Dans d’autres modes de réalisation, la réception de la réponse d’autorisation de transaction est en réponse à l’envoi d’une demande d’autorisation de transaction au dispositif du titulaire de carte. Par conséquent, la confirmation de transaction par la saisie/sélection/confirmation du deuxième CVV peut avoir lieu dans le processus classique d’autorisation de transaction, dans lequel le dispositif du titulaire de carte est en outre sollicité via la demande d’autorisation de transaction. La demande d’autorisation de transaction comprend de préférence les informations de transaction (à afficher au client) pour permettre au titulaire de carte de valider la transaction en ayant une connaissance suffisante de celle-ci.
Dans des modes de réalisation spécifiques, l’envoi de la demande d’autorisation de transaction est en réponse à la réception d’une demande de transaction du système marchand, la demande de la transaction comportant le premier CVV et les informations de transaction.
Dans certains modes de réalisation, la transaction est approuvée lorsque le deuxième CVV est égal à une valeur attendue basée sur le premier CVV. Notamment, les premier et deuxième CVV peuvent être les mêmes, ce qui signifie que la valeur attendue est le premier CVV. En effet, comme le titulaire de carte peut choisir librement le CVV pour la transaction, la validation de celle-ci est faite de préférence lorsque le CVV de confirmation (le deuxième), entré lors du processus d’autorisation de transaction, est le même que le CVV initial. Dans une variante, la valeur attendue peut être une valeur de référence, résultat d’une opération secrète (connue du titulaire de carte et du système de paiement) sur le premier CVV connu. Par exemple, la valeur de référence peut être le résultat d’une addition du premier CVV et d’une valeur personnelle et/ou secrète (par exemple l’année de naissance).
Dans certains modes de réalisation, la réponse d’autorisation de transaction est reçue avec une première signature numérique de celle-ci, calculée sur la base d’un jeton de paiement par carte (par exemple des éléments d’accréditation dédiés à la signature numérique) stocké sur le dispositif du titulaire de carte. Un jeton de paiement par carte résulte classiquement de la tokenisation d’une carte de paiement qui sécurise les informations de paiement (PAN et date d’expiration) dans le dispositif du titulaire de carte. La signature de la réponse augmente la sécurisation du processus d’autorisation.
Dans des modes de réalisation spécifiques, l’approbation ou le refus de la transaction comporte le calcul d’une deuxième signature numérique sur la base du premier CVV et d’un jeton de paiement par carte généré localement (en utilisant le même processus de tokenisation) pour le titulaire de carte, et la comparaison des première et deuxième signatures numériques.
Dans certains modes de réalisation, la transaction est refusée si le premier CVV est le même qu’un CVV utilisé au cours de l’une des dernières transactions (généralement dans l’une des N dernières transactions précédentes pour le titulaire de carte, N étant un nombre entier).
Du point de vue du titulaire de carte, dans certains modes de réalisation, l’entrée de la confirmation de transaction par l’utilisateur comporte l’entrée du deuxième CVV sur le dispositif du titulaire de carte ou la sélection du deuxième CVV dans une liste de CVV affichés sur le dispositif du titulaire de carte ou la confirmation d’un CVV affiché sur le dispositif du titulaire de carte (par exemple le premier CVV est affiché pour confirmation, ou divers CVV comportant le premier CVV ou un CVV de référence équivalent sont affichés successivement, en attendant une confirmation par l’utilisateur lorsque le bon CVV est affiché) comme étant le deuxième CVV.
Dans certains modes de réalisation, l’entrée de la confirmation de transaction par l’utilisateur est en réponse à une demande d’autorisation de transaction par le système de paiement qui affiche les informations de la transaction sur le dispositif du titulaire de carte.
Dans d’autres modes de réalisation, le deuxième CVV est égal à une valeur de référence basée sur le premier CVV, par exemple les premier et deuxième CVV sont identiques, pour recevoir une approbation de la transaction. Là encore, le premier CVV peut être sélectionné librement par le titulaire de carte.
Dans des modes de réalisation, le procédé comprend en outre l’envoi, par le dispositif du titulaire de carte, d’une réponse d’autorisation de transaction, comportant la confirmation de transaction par l’utilisateur (c’est-à-dire basée sur le deuxième CVV), au système de paiement. La réponse d’autorisation de transaction peut être accompagnée d’une signature numérique de celle-ci calculée sur la base d’un jeton de paiement par carte stocké sur le dispositif du titulaire de carte.
Dans certains modes de réalisation, le procédé comprend en outre l’affichage préalable (c’est-à-dire avant que le premier CVV ne soit entré par le client) d’informations de jeton de paiement par carte sur un écran du dispositif du titulaire de carte, dans lequel le premier CVV est entré dans le système marchand avec les informations affichées de jeton de paiement par carte (c’est-à-dire dans le même formulaire de paiement ou succession de formulaires pour la même transaction). De telles informations comportent généralement un PAN tokenisé et une date d’expiration. Le premier CVV et ces informations sont donc saisis ensemble, c’est-à-dire dans le même formulaire de paiement pour la transaction ou dans la même succession de formulaires pour la même transaction.
Un autre aspect de l’invention concerne un support non transitoire lisible par ordinateur stockant un programme qui, lorsqu’il est exécuté par un microprocesseur ou un système informatique, amène le système à effectuer tout procédé tel que défini ci-dessus.
Au moins une partie des procédés selon l’invention peut être mise en œuvre par ordinateur. En conséquence, la présente invention peut prendre la forme d’un mode de réalisation entièrement matériel, d’un mode de réalisation entièrement logiciel (comportant les microprogrammes, les logiciels résidents, les microcodes, etc.) ou d’un mode de réalisation combinant des aspects logiciels et matériels qui peuvent tous être globalement appelés ici "circuit", "module" ou "système". De plus, la présente invention peut prendre la forme d’un produit de programme informatique incorporé dans tout support d’expression tangible disposant d’un code de programme utilisable par ordinateur incorporé dans le support.
Étant donné que la présente invention peut être mise en œuvre dans un logiciel, la présente invention peut être incorporée sous forme de code lisible par ordinateur pour être fournie à un appareil programmable sur tout support adapté. Un support tangible peut comprendre un support de stockage tel qu’un lecteur de disque dur, un dispositif de bande magnétique ou un dispositif de mémoire à semi-conducteurs et analogues. Un support transitoire peut comporter un signal tel qu’un signal électrique, un signal électronique, un signal optique, un signal acoustique, un signal magnétique ou un signal électromagnétique, par exemple un signal hyperfréquence ou RF (radiofréquence).
Les modes de réalisation de l’invention seront maintenant décrits, à titre d’exemple uniquement, et en référence aux dessins suivants dans lesquels :
La illustre un système de transaction dans lequel les modes de réalisation de la présente invention peuvent être mis en œuvre,
La illustre des échanges de messages donnés à titre d’exemple pour mettre en œuvre des modes de réalisation de la présente invention,
La illustre, à l’aide d’un organigramme, des étapes données à titre d’exemple pour mettre en œuvre la présente invention du côté d’un titulaire de carte, et
La illustre, à l’aide d’un organigramme, des étapes données à titre d’exemple pour mettre en œuvre la présente invention du côté d’un système de paiement.
Description détaillée
L’invention s’applique aux transactions financières et plus particulièrement aux transactions sans présence de la carte, comme par exemple l’achat d’un ou plusieurs produits sur un site web. La carte utilisée pour le paiement n’est pas glissée ou sa puce n’est pas lue. Le client doit saisir les informations de la carte de paiement, telles qu’un PAN, une date d’expiration et une valeur de vérification de carte appelée CVV ou CVC ou CSC. Ci-dessous, il est fait référence au CVV pour désigner tout type de valeur de vérification de carte. Un processus d’autorisation est ensuite exécuté dans le système de paiement ou l’infrastructure sous-jacente au système marchand, pour vérifier la transaction, les informations de paiement et le solde de compte du titulaire de carte par exemple. Une autorisation (ou un refus) est alors émise pour valider l’achat, le montant d’achat étant transféré du compte bancaire du titulaire de carte au compte bancaire du marchand dans le système de paiement.
Bien qu’il soit fait référence ci-dessous aux transactions en ligne (sur Internet), d’autres transactions sans présence de la carte peuvent être envisagées dans le cadre de la présente invention, à condition qu’un CVV soit entré en plus des informations de carte de paiement (par exemple le PAN et la date d’expiration). Celles-ci comportent notamment des transactions de vente par correspondance par mail ou fax, ou des transactions par téléphone.
La illustre un système 1 permettant de mettre en œuvre une transaction sans présence de la carte selon des modes de réalisation de l’invention.
Le système 1 comprend un environnement ou système de titulaire de carte 10, un environnement, infrastructure ou système marchand 20 et un environnement, infrastructure ou système de paiement 30.
Le système de titulaire de carte 10 comprend une carte de paiement 11 du titulaire de carte, un dispositif d’accès 12 pour accéder au système marchand 20 et un dispositif personnel du titulaire de carte 13.
La carte de paiement 11 peut être de tout type, avec ou sans bande magnétique, avec ou sans puce sécurisée. Elle peut être fournie sous la forme d’un support physique ou sous forme électronique. La carte de paiement 11 comporte habituellement un nom de titulaire de carte, un PAN et une date d’expiration, tous ces éléments étant par exemple imprimés ou mis en relief sur la carte physique. Certaines cartes de paiement sont en outre pourvues d’un CVV joint, par exemple elles comportent un CVV imprimé au recto ou au verso. Le CVV peut être un code à trois chiffres (notamment pour les cartes Visa et Mastercard – marques déposées) ou peut être un code à quatre chiffres (notamment pour American Express – marque déposée). Bien entendu, un nombre quelconque de chiffres peut être envisagé dans la portée de la présente invention. Certaines cartes de paiement n’ont pas de CVV imprimé sur celles-ci.
La carte de paiement 11 peut être soumise à une tokenisation dans le dispositif personnel du titulaire de carte 13. Cela signifie qu’une partie ou la totalité des informations de carte (généralement un PAN) est convertie en code numérique ou codes numériques (généralement un PAN tokenisé) également appelé "jeton". Le jeton, référencé 133 dans la figure, peut être utilisé, comme alternative aux informations de carte réelle, pour un paiement de transaction : le PAN tokenisé se substitue alors au PAN réel, sécurisant ainsi la carte de paiement. Pour effectuer la tokenisation, le titulaire de carte peut enregistrer son dispositif personnel 13 auprès de sa banque (référence 32 discutée ci-dessous), permettant ainsi à cette banque d’échanger directement des messages avec le titulaire de carte. Bien entendu, dans une variante, le titulaire de carte peut simplement se connecter à la banque en utilisant l’application bancaire 132 (par exemple en utilisant un accès par login et mot de passe).
Le dispositif d’accès 12 peut être tout système accédant au système marchand 20 : un navigateur web, un téléphone, un fax, un courrier, etc. De préférence, il comporte un ordinateur équipé d’un navigateur web permettant d’accéder à un site web marchand. L’ordinateur peut être le dispositif personnel du titulaire de carte 13 (par exemple un téléphone intelligent équipé d’un navigateur web) ou peut être un ordinateur distinct.
Le dispositif personnel de titulaire de carte 13 est de préférence un dispositif portable, tel qu’un téléphone mobile ou intelligent, une tablette, un ordinateur portable, un organiseur personnel, etc. Il comporte des interfaces E/S (entrée/sortie) 130 (par exemple clavier et écran), des applications telles qu’un navigateur web 131 si le dispositif fonctionne comme dispositif d’accès 12 et une application bancaire, par exemple une application logicielle de portefeuille ou "portefeuille électronique" ou "e-portefeuille" 132, pour mettre en œuvre les mécanismes de la présente invention. Le e-portefeuille 132 stocke le jeton de paiement par carte 133.
Le système marchand 20 est essentiellement un ou plusieurs serveurs marchands 21 classiques qui hébergent un site web marchand doté de fonctionnalités de paiement et de transaction pour l’achat de produits. Tout réseau de communication, par exemple un réseau mobile ou Internet, peut être utilisé pour connecter le dispositif d’accès 12 au serveur ou aux serveurs du système marchand 20.
Les serveurs marchands 21, et plus précisément celui ou ceux qui gèrent les fonctionnalités de transaction, sont connectés au système de paiement 30 par tout type de réseau de communication, généralement l’Internet. Les serveurs marchands peuvent être mis en œuvre par le commerçant lui-même et/ou par des tiers fournissant au commerçant des fonctionnalités de vente et de paiement.
Une transaction est conventionnellement initiée dans le système marchand 20 lorsqu’un client achète des produits sur le site web marchand.
Pour initier la transaction, le client saisit les informations de sa carte de paiement sur un formulaire de paiement, déclenchant ainsi un processus d’autorisation de transaction entre les serveurs marchands 21 et le système de paiement 30. Selon les modes de réalisation de l’invention, le client (normalement le titulaire de carte) fournit, entre ou tape, en plus des informations de carte, un CVV. Le CVV est avantageusement sélectionné librement par le client/titulaire de carte, toute valeur entre 0 et 999 pour un CVV à 3 chiffres ou entre 0 et 9999 pour un CVV à 4 chiffres. La sélection libre peut être mise en œuvre même si la carte de paiement 11 a un CVV imprimé sur celle-ci. Cela permet au titulaire de carte d’avoir un meilleur contrôle sur la sécurisation de la transaction basée sur le CVV. Cela permet également au titulaire de carte de continuer à utiliser sa carte de paiement même si le CVV a été piraté (dans ce cas, le CVV imprimé peut avoir été désactivé auprès de la banque du titulaire de carte de sorte que la présente invention soit mise en œuvre chaque fois que la carte est utilisée).
Ce n’est que lorsqu’une réponse d’autorisation approuvant la transaction est reçue du système de paiement 30, que les serveurs marchands 21 peuvent informer le client que son achat est validé, ce qui signifie que la transaction est approuvée.
Le système de paiement 30 gère le processus d’autorisation de transaction, et effectue donc des échanges de messages nécessaires entre la banque du commerçant (ou "banque acquéreuse" ou serveur de réception des transactions) 31 et la banque du titulaire de carte (ou "banque émettrice") 32. Le système de paiement 30 repose habituellement sur un plus grand nombre d’équipements (par exemple des passerelles de paiement, des serveurs, …). Pour faciliter l’illustration, seules la banque du commerçant et la banque du titulaire de carte sont montrées sous la forme de serveurs distincts.
Les serveurs bancaires sont en mesure d’échanger des messages afin de procéder au processus d’autorisation d’une transaction sous-jacente, la banque du commerçant 31 fournissant en fin de compte au système marchand 20 l’approbation ou le refus de la transaction sous-jacente. Dans ce processus, la banque du titulaire de carte 32 vérifie habituellement les informations de transaction et vérifie si le titulaire de carte (identifié sur la base du PAN) est autorisé à effectuer la transaction (par exemple en ce qui concerne le montant de la transaction et le solde de compte bancaire).
Selon les modes de réalisation de l’invention, la banque du titulaire de carte 32, au cours d’un processus de transaction, envoie une demande d’autorisation de transaction au dispositif du titulaire de carte 13 pour demander au titulaire de carte de confirmer la transaction et fournir ou confirmer le CVV entré lors de l’initiation de la transaction. La confirmation de la transaction peut simplement résulter du fait de taper correctement le CVV initial par le titulaire de carte sur le dispositif du titulaire de carte ou d’entrer un CVV qui doit concorder avec un CVV de référence, basé sur le CVV initial.
Cela permet de s’assurer que le client a accès au dispositif du titulaire de carte, c’est-à-dire qu’il est en possession d’éléments d’accréditation représentant la carte de paiement utilisée.
La banque du titulaire de carte 32 peut avoir le contrôle de l’application bancaire 132 de telle sorte que les détails de la transaction puissent être affichés au titulaire de carte en vue d’effectuer la confirmation de transaction.
Les figures 2 à 4 illustrent des procédés de traitement d’une transaction sans présence de la carte selon des modes de réalisation de l’invention.
La illustre des échanges de messages entre les entités montrées sur la pour effectuer une transaction. Les figures 3 et 4 illustrent des étapes générales du procédé pour effectuer la transaction, respectivement dans l’environnement de client/titulaire de carte 10 et dans l’infrastructure de paiement 30, selon des modes de réalisation de l’invention. Les étapes générales du procédé au niveau du système marchand sont des étapes classiques. Par conséquent, elles ne sont pas montrées pour faciliter l’illustration.
D’abord (étape 200), la carte de paiement 11 du titulaire de carte est soumise à une tokenisation dans l’application bancaire (e-portefeuille) 132 du dispositif personnel du titulaire de carte 13. Cette étape est facultative puisque le titulaire de carte, en tant que client, a le choix d’utiliser soit les informations de carte imprimées ou mises en relief sur la carte 11, soit les informations tokenisées fournies par l’application bancaire 132 lorsqu’il effectue une transaction avec un commerçant.
La tokenisation fournit un jeton de paiement constitué d’un PAN tokenisé avec la date d’expiration dans le e-portefeuille 132. Facultativement, un ensemble d’éléments d’accréditation peut être généré comme données supplémentaires au jeton de paiement. Les éléments d’accréditation peuvent comporter une ou plusieurs clés (de paiement), de préférence dédiées à des usages spécifiques respectifs. Les éléments d’accréditation peuvent être des éléments d’accréditation à usage unique, des éléments d’accréditation à durée limitée, auquel cas le dispositif personnel 13 peut demander de nouveaux éléments d’accréditation si nécessaire. Les éléments d’accréditation peuvent également être illimités (en termes d’utilisation et de temps) et être diversifiés localement à la volée pour fournir des éléments d’accréditation spécifiques pour des usages spécifiques.
À l’étape 205, composée des étapes 206 à 209, le titulaire de carte initie une transaction avec le commerçant :
À l’étape 206, le titulaire de carte peut par exemple accéder à un site web marchand en utilisant le navigateur web 12, ajouter quelques produits dans un panier et accéder à un formulaire de paiement affichant un montant total à payer.
À l’étape 207, le titulaire de carte récupère ses informations de carte de paiement pour les entrer dans le formulaire de paiement. Sans tokenisation de la carte de paiement 11, le titulaire de carte lit le PAN en relief sur sa carte 11, ainsi que la date d’expiration de la carte. En cas de tokenisation de la carte, le titulaire de carte accède au e-portefeuille 132 sur son dispositif 13 et y sollicite un nouveau paiement en ligne. Le e-portefeuille fournit une fonction d’affichage numérique qui, lorsqu’elle est sollicitée pour un nouveau paiement en ligne, affiche un PAN tokenisé numérique et la date d’expiration à utiliser pour le paiement en ligne.
À l’étape 208, le titulaire de carte saisit les informations de carte de paiement dans le formulaire de paiement du site web marchand. Les informations de carte de paiement sont donc entrées dans le système marchand 20.
À l’étape 209, le titulaire de carte sélectionne une valeur de vérification de carte, CVV, indépendamment de tout CVV imprimé sur la carte, et la saisit dans le formulaire de paiement. Le CVV est appelé ci-dessous "CVV de transaction". Il peut être une valeur à 3 chiffres, ou une valeur à 4 chiffres. En variante, il peut comprendre un autre nombre de chiffres.
Le nombre de chiffres pour le CVV de transaction est connu du titulaire de carte, par exemple comme nombre de chiffres d’un CVV déjà imprimé sur la carte 11.
Le titulaire de carte peut sélectionner librement (donc manière pseudo-aléatoire) le CVV de transaction dans la plage des valeurs possibles : [0-999] pour un CVV à 3 chiffres, [0-9999] pour une valeur à 4 chiffres. Dans certains modes de réalisation, le CVV de transaction doit être différent d’un CVV déjà imprimé sur la carte (le cas échéant). Cela aide le système de paiement 30 (en particulier la banque du titulaire de carte 32) à savoir si le présent procédé est en cours d’exécution (pour envoyer des demandes d’autorisation de transaction aux dispositifs du titulaire de carte) ou si un processus classique doit être appliqué (CVV prédéfini vérifié du côté de la banque).
En variante, le e-portefeuille 132 peut générer de manière aléatoire un CVV de transaction (à usage unique) avec le nombre de chiffres approprié. Le titulaire de carte doit alors entrer le CVV de transaction généré.
Dans certains modes de réalisation, le CVV de transaction est sélectionné dans une sous-partie d’une plage de valeurs possibles. Par exemple, pour une valeur à trois chiffres, le CVV de transaction est sélectionné dans la plage [500-999], donnant la possibilité au système de paiement 30 de savoir quand le présent procédé est en cours d’exécution (CVV égal ou supérieur à 500) ou quand un processus classique doit être appliqué (CVV < 500).
Dans d’autres modes de réalisation, le CVV de transaction peut avoir un nombre prédéfini de chiffres pour identifier s’il s’agit d’un CVV de transaction choisi librement. Par exemple, si un CVV à 3 chiffres (en variante à 4 chiffres ou un nombre quelconque N de chiffres) est imprimé sur la carte, le titulaire de carte choisit librement un CVV à 4 chiffres (en variante à 3 chiffres ou un nombre quelconque différent de N). Cela aide le système de paiement 30 à savoir si le présent procédé est en cours d’exécution (si le CVV est à 4 chiffres) ou si un processus classique doit être appliqué (si le CVV est à 3 chiffres).
Dans d’autres modes de réalisation encore, la valeur du PAN fourni peut indiquer au système de paiement 30 qu’un CVV sélectionné librement est utilisé. Par exemple, si le PAN imprimé/en relief est utilisé, le CVV imprimé doit être fourni, tandis que lorsqu’un PAN tokenisé numérique est utilisé, le client doit sélectionner librement son CVV.
Le client/titulaire de carte valide le formulaire de paiement en cliquant sur un bouton "payer" approprié. Cette validation envoie toutes les informations de paiement (PAN ou PAN tokenisé, date d’expiration, CVV de transaction) au serveur marchand 21 (étape 210).
Le serveur marchand 21 initie la transaction de manière classique (étape 215) : une demande de transaction est envoyée à la banque du commerçant 31. La demande comporte des informations de transaction telles que le montant de la transaction, la date et l’heure de la transaction, le PAN tokenisé (ou PAN réel), la date d’expiration et le CVV de transaction entré par le consommateur, ainsi qu’un identifiant de commerçant permettant de déterminer le compte bancaire du commerçant. D’autres informations qui n’ont pas d’importance pour la présente invention peuvent être ajoutées.
La banque du commerçant 31 transmet ensuite la demande sous forme de demande d’autorisation de transaction à la banque du titulaire de carte 32. La demande d’autorisation de transaction peut être le même message que la demande de transaction ou un message différent de celui-ci (c’est-à-dire avec des champs de données différents). La banque du titulaire de carte 32 peut être identifiée par la banque du commerçant 31 grâce au PAN tokenisé (ou PAN réel) indiqué dans la demande de transaction. La demande d’autorisation de transaction comporte des informations de transaction telles que le PAN tokenisé (ou réel), la date d’expiration, le CVV de transaction et le montant et la date/heure de la transaction. Il s’agit de l’étape 220 qui est classique, et n’est donc pas décrite avec plus de détails.
Dès réception de la demande, la banque du titulaire de carte 32 identifie le compte bancaire du titulaire de carte grâce au PAN tokenisé (ou réel) et effectue des vérifications classiques (par exemple la date d’expiration, le solde de compte bancaire en ce qui concerne le montant de la transaction, et ainsi de suite.). Il s’agit de l’étape 225.
À l’étape 226, la banque du titulaire de carte 32 détermine si une confirmation du CVV par l’utilisateur est requise, c’est-à-dire si le client utilise un CVV imprimé sur la carte de paiement 11 ou non.
Une confirmation du CVV peut être requise si la carte de paiement 11 est fournie au titulaire de carte sans CVV imprimé ou si le CVV imprimé a été désactivé ou déclaré comme piraté. Cela peut également être le cas si le CVV de transaction fourni dans la demande d’autorisation de transaction se trouve dans une plage de valeurs dédiée (par exemple [500-999] dans l’exemple ci-dessus) ou si le CVV a un nombre prédéfini de chiffres (par exemple un nombre de chiffres différent du CVV imprimé sur la carte 11) ou est différent d’un CVV imprimé sur la carte de paiement utilisé. Une confirmation de CVV peut également être requise en fonction du PAN fourni, par exemple s’il s’agit d’un PAN tokenisé.
Si aucune confirmation de CVV par l’utilisateur n’est requise, un traitement classique (non montré) est effectué, notamment l’acceptation ou le refus de la transaction est renvoyé à la banque du commerçant 31, ou une confirmation de transaction est simplement sollicitée auprès du titulaire de carte de manière classique.
Si une confirmation par l’utilisateur est requise pour le CVV de transaction, la banque du titulaire de carte 32 appelle l’application bancaire 132 dans le dispositif du titulaire de carte 13 avec une demande d’autorisation de transaction. Il s’agit de l’étape 227 avec la demande d’autorisation de transaction envoyée au dispositif personnel du titulaire de carte 13.
Selon des modes de réalisation, la demande d’autorisation de transaction ne comprend pas de CVV de transaction. Dans des variantes, elle comporte le CVV de transaction en vue de l’afficher à l’utilisateur (titulaire de carte/client) pour validation ou sélection.
La demande d’autorisation de transaction identifie la transaction (par exemple l’identification du commerçant, le montant total du paiement, la date et l’heure de la transaction). Elle est interprétée par l’application bancaire 132 (e-portefeuille) comme une commande d’affichage pour afficher les informations de transaction sur un écran du dispositif du titulaire de carte 13 en vue d’obtenir une confirmation de transaction utilisateur par le titulaire de carte.
Dans certains modes de réalisation, la commande d’affichage fournit un champ de saisie pour que le titulaire de carte saisisse ou tape ou entre le CVV de transaction utilisé à l’étape 209 pour la transaction. C’est par exemple le cas lorsque la demande d’autorisation de transaction ne comprend pas de CVV de transaction.
Dans une variante à la saisie du CVV de transaction, le client peut être invité à entrer une valeur ou CVV de référence qui est basé sur le CVV de transaction, par exemple par l’ajout, au CVV de transaction, d’une valeur secrète connue de la banque du titulaire de carte 32 et du titulaire de carte. Par exemple, un CVV de transaction à 4 chiffres peut être ajouté à l’année de naissance du titulaire de carte pour obtenir le CVV de référence à saisir par le titulaire de carte.
Le CVV attendu du titulaire de carte, quel que soit le CVV de transaction ou de référence, est appelé CVV attendu.
Dans d’autres modes de réalisation, la commande d’affichage fournit des CVV sélectionnables comportant le CVV attendu et des CVV générés de manière aléatoire, pour que le titulaire de carte sélectionne le CVV attendu correct. Dans une variante, la commande d’affichage fournit un affichage du CVV attendu pour confirmation par l’utilisateur uniquement. C’est par exemple le cas lorsque la demande d’autorisation de transaction comporte le CVV de transaction ou le CVV de référence s’il est calculé par la banque du titulaire de carte 32.
À l’étape 230, le titulaire de carte vérifie les informations de transaction ainsi affichées. Il peut confirmer la transaction en saisissant un CVV dans le champ de saisie (appelé "CVV de confirmation"), ou en sélectionnant un CVV parmi les CVV sélectionnables, ou simplement en confirmant visuellement le CVV affiché, et en appuyant sur un bouton "validation". Le titulaire de carte peut également décliner la transaction (par exemple s’il n’est pas l’acheteur) en appuyant sur un bouton "refus".
Cette action du titulaire de carte/client est une confirmation de transaction utilisateur.
L’appui sur l’un ou l’autre bouton déclenche l’envoi (étape 235) d’une réponse d’autorisation de transaction à la banque du titulaire de carte 32. La réponse comporte le CVV de confirmation, le cas échéant, saisi ou sélectionné ou confirmé à l’étape 230.
Dans certains modes de réalisation, la réponse d’autorisation de transaction est signée numériquement à l’étape facultative 234. La signature numérique est effectuée sur la base d’un élément d’accréditation du jeton de paiement 133. Un élément d’accréditation à usage unique ou à durée limitée pour la signature numérique est utilisé, ou un élément d’accréditation spécifique est diversifié à partir d’un élément d’accréditation racine pour la signature numérique et ensuite utilisé.
Cette signature numérique garantit les détails de la transaction (informations) validés par le titulaire de carte. Cela fournit une couche de sécurité, notamment contre une personne intermédiaire (« man in the middle » en langue anglo-saxonne) qui souhaiterait modifier le montant de la transaction entre les diverses demandes et réponses échangées.
La signature est envoyée avec la réponse d’autorisation de transaction. En cas d’utilisation d’un élément d’accréditation spécifique diversifié localement, un index ou toute autre information (par exemple un diversificateur) peut être inclus dans la réponse pour que la banque du titulaire de carte soit en mesure de régénérer localement le même élément d’accréditation spécifique (à des fins de vérification de la signature).
À l’étape 240, la banque du titulaire de carte 32 prend une décision d’autorisation de transaction sur la base de la réponse ainsi reçue, facultativement avec la signature numérique.
Cela peut comporter une étape facultative 241 consistant à vérifier la signature numérique jointe à la réponse reçue.
Pour ce faire, la banque du titulaire de carte 32 peut générer localement le même jeton, avec des éléments d’accréditation comme ce qui a été fait précédemment (étape 200) dans le dispositif personnel du titulaire de carte 13, ou simplement récupérer l’élément d’accréditation pour la signature numérique à partir d’une mémoire locale s’il a déjà été généré, ou diversifier un élément d’accréditation en utilisant l’index ou le diversificateur spécifié dans la réponse reçue, pour obtenir l’élément d’accréditation spécifique diversifié. Cela est possible puisque la banque 32 a connaissance de toutes les informations de la carte de paiement.
Les mêmes éléments d’accréditation sont ensuite utilisés pour générer localement une autre signature numérique basée sur le CVV attendu (c’est-à-dire de transaction ou de référence) et les informations de transaction. Par exemple, un message similaire à la réponse d’autorisation reçue de transaction est construit, mais qui comprend les informations de transaction et le CVV attendu. La signature est ensuite calculée à partir de ce message. La signature générée localement et la signature reçue sont ensuite comparées l’une à l’autre. La réponse d’autorisation de transaction ne peut être traitée que si les deux signatures sont identiques, ce qui signifie que la réponse est fiable. Il en résulte qu’une approbation de la transaction elle-même ne peut être décidée que si les deux signatures sont les mêmes (la vérification de la signature est positive).
La prochaine étape 242 consiste, pour la banque du titulaire de carte 32, à vérifier le CVV de confirmation (reçu à l’étape 235) avec le CVV attendu qui est basé sur le CVV de transaction (reçu à l’étape 220). La transaction sous-jacente peut être approuvée si le CVV de confirmation et le CVV attendu sont les mêmes.
Dans la décision, la banque du titulaire de carte 32 peut également prendre en compte (étape 243) les résultats des vérifications classiques de l’étape 225 (carte de paiement encore valide au regard de la date d’expiration et/ou le solde de compte bancaire suffisant au regard du montant de la transaction, et ainsi de suite.).
Dans certains modes de réalisation, la banque du titulaire de carte 32 peut également vérifier (étape 244) que le CVV utilisé (au cas où la vérification de CVV à l’étape 242 est positive) n’est pas le même que ceux utilisés au cours des N dernières transactions (nombre entier) pour la même carte de paiement 11. À cette fin, la banque du titulaire de carte 32 peut enregistrer dans une mémoire d’historique tous les CVV impliqués dans les transactions pour le titulaire de carte. De préférence, seuls les CVV d’une transaction approuvée sont enregistrés. La transaction peut être refusée si le CVV de transaction est le même qu’un CVV utilisé au cours d’une transaction précédente.
Comme la signature numérique est facultative, l’étape 241 est facultative. Lorsqu’une signature numérique est mise en œuvre, l’étape 242 peut être facultative. En effet, une vérification de signature positive (étape 241) est suffisante car elle signifie que le CVV de confirmation (par la signature reçue) est égal au CVV attendu (par la signature générée localement).
Une fois que la banque du titulaire de carte 32 a pris la décision d’autorisation de transaction, elle envoie une réponse d’autorisation de transaction à la banque du commerçant 31 (étape 245) indiquant l’approbation ou le refus de la transaction sous-jacente. Un identifiant unique de la transaction peut être suivi dans tous les messages échangés dans le système 1 pour faciliter la gestion de la transaction sous-jacente parmi une multitude de transactions simultanées.
La décision de transaction (telle que spécifiée dans la réponse) est traitée de manière classique par la banque du commerçant 31 : la décision est transmise au système marchand (étape 250), et en cas d’approbation de la transaction, le transfert d’argent entre les deux banques est initié et réalisé.
Le serveur marchand 21 traite ensuite la décision de manière encore classique, en affichant au client le résultat de la transaction dans le navigateur web 12 : achat confirmé ou transaction refusée (étape 255).
Certaines étapes du processus peuvent être faites simultanément ou leur ordre peut être modifié. Notamment, l’ordre des étapes 241 à 244 n’a pas vraiment d’importance.
Comme le montre la , le titulaire de carte, en tant que client souhaitant effectuer une transaction, affiche d’abord, à l’étape facultative 300, des informations de jeton de paiement par carte sur un écran de son dispositif de titulaire de carte 13, tel qu’un PAN tokenisé et une date d’expiration de la carte.
Ensuite, le titulaire de carte entre, à l’étape 305, des informations de paiement et un CVV de transaction dans le système marchand 20 connecté au système de paiement 30, pour initier la transaction via le système marchand. Cela peut se faire dans un formulaire de paiement dans un navigateur web accédant à un site web marchand.
Comme le montre la , le système de paiement 30 (la banque du commerçant 31) reçoit donc à l’étape 400 une demande de transaction à partir du système marchand 20, la demande de la transaction comportant le CVV de transaction et les informations de transaction.
À l’étape 405, le système de paiement 30 (la banque du titulaire de carte 32) envoie une demande d’autorisation de transaction au dispositif personnel du titulaire de carte 13. L’envoi répond à la réception de la demande de transaction en provenance du système marchand 20. Certains échanges de messages entre la banque du commerçant et la banque du titulaire de carte pilotent le processus de réponse.
À l’étape 310, la demande d’autorisation de transaction est reçue par le dispositif du titulaire de carte 13, ce qui déclenche un affichage des informations de transaction sur le dispositif du titulaire de carte 13 et invite le titulaire de carte à entrer le CVV attendu (CVV de transaction ou de référence, le cas échéant) à des fins de confirmation ou à sélectionner un CVV parmi les CVV sélectionnables affichés (comportant le CVV attendu) ou à confirmer visuellement le CVV attendu affiché.
À l’étape 315, le titulaire de carte saisit un CVV ou sélectionne un CVV sélectionnable ou confirme un CVV affiché, tous appelés CVV de confirmation, sur le dispositif de titulaire de carte 13 et confirme (ou décline) la transaction affichée.
Celui-ci génère et envoie une réponse d’autorisation de transaction au système de paiement, à l’étape 320.
À l’étape 410, le système de paiement 30 (la banque du titulaire de carte 32) reçoit la réponse à la demande d’autorisation de transaction depuis le dispositif du titulaire de carte 13. La réponse est basée sur le CVV de confirmation et peut facultativement être accompagnée d’une signature numérique comme mentionné ci-dessus.
À l’étape 415, le système de paiement 30 approuve (accepte, autorise, confirme, valide) ou refuse (décline, rejette) la transaction sur la base des CVV de transaction et de confirmation. En particulier, la transaction est approuvée lorsque les deux CVV sont un seul et même CVV ou lorsque le CVV de confirmation est égal au CVV de référence. D’autres critères tels que décrits ci-dessus peuvent être utilisés pour approuver ou refuser la transaction, par exemple le CVV comparé aux CVV utilisés dans les transactions précédentes ou le solde du compte du titulaire de carte.
À l’étape 420, la décision d’autorisation de transaction est envoyée au système marchand 20.
À l’étape 325, le titulaire de carte, via le navigateur web ou analogues, reçoit par le biais du système marchand l’approbation ou le refus de la transaction.
La présente invention, dont les modes de réalisation sont décrits ci-dessus, permet d’améliorer la sécurité des transactions en ligne. En effet, le titulaire de carte garde le contrôle sur la validation de toute transaction impliquant sa carte de paiement. De plus, les CVV sont protégés contre les utilisations frauduleuses puisqu’ils ont une durée de vie courte, qu’ils sont générés pour chaque nouvelle transaction et qu’ils nécessitent une confirmation par le titulaire de carte lui-même.
Par ailleurs, la présente invention ne modifie pas les systèmes marchands existants et réutilise l’infrastructure de paiement existante en ajoutant uniquement un module de confirmation de CVV auprès des banques des titulaires de cartes. L’avantage est qu’en laissant le titulaire de carte choisir les CVV sans génération dynamique, les contraintes de certification PCI sur les serveurs gérant la carte de paiement sont réduites.
Bien que la présente invention ait été décrite ci-dessus en référence à des modes de réalisation spécifiques, la présente invention n’est pas limitée à ces modes de réalisation spécifiques, et des modifications, qui se trouvent dans la portée de la présente invention, seront visibles pour un homme du métier.
De nombreuses autres modifications et variations s’imposeront à ceux qui sont versés dans l’art en se référant aux modes de réalisation illustratifs ci-dessus, qui ne sont donnés qu’à titre d’exemple et qui ne viennent pas limiter la portée de l’invention, celle-ci étant déterminée uniquement par les revendications annexées. En particulier, les différentes caractéristiques des différents modes de réalisation peuvent être échangés, le cas échéant.
Dans les revendications, le mot "comprenant" n’exclut pas d’autres éléments ou étapes, et l’article indéfini "un" ou “une" n’exclut pas une pluralité. Le simple fait que des caractéristiques différentes sont citées dans des revendications dépendantes mutuellement différentes n’indique pas qu’une combinaison de ces caractéristiques ne peut pas être utilisée avantageusement.

Claims (15)

  1. Procédé pour effectuer une transaction sans présence d’une carte, le procédé comprenant, au niveau d’un système de paiement (30) :
    la réception (400) d’une première valeur de vérification de carte, CVV, avec des informations de transaction en provenance d’un système marchand (20),
    la réception (410), à partir d’un dispositif du titulaire de carte (13), d’une réponse d’autorisation de transaction qui est basée sur un deuxième CVV, et
    l’approbation ou le refus (240, 415) de la transaction sur la base des premier et deuxième CVV.
  2. Procédé de la revendication 1, dans lequel le premier CVV est entré par le titulaire de carte dans le système marchand (20) et le deuxième CVV est entré par le titulaire de carte sur le dispositif du titulaire de carte (13) ou est sélectionné par le titulaire de carte dans une liste de CVV affichés sur le dispositif du titulaire de carte ou est confirmé par le titulaire de carte lorsqu’il est affiché sur le dispositif du titulaire de carte.
  3. Procédé de la revendication 1 ou 2, dans lequel la réception (410) de la réponse d’autorisation de transaction est en réponse à l’envoi (405) d’une demande d’autorisation de transaction au dispositif du titulaire de carte (13).
  4. Procédé de la revendication 3, dans lequel l’envoi (405) de la demande d’autorisation de transaction est en réponse à la réception (400) d’une demande de transaction du système marchand, la demande de la transaction comportant le premier CVV et les informations de transaction.
  5. Procédé de l’une des revendications 1 à 4, dans lequel la transaction est approuvée (240, 415) lorsque le deuxième CVV est égal à une valeur attendue basée sur le premier CVV.
  6. Procédé de l’une des revendications 1 à 5, dans lequel la réponse d’autorisation de transaction est reçue avec une première signature numérique de celle-ci, calculée (234) sur la base d’un jeton de paiement par carte (133) stocké sur le dispositif du titulaire de carte (13).
  7. Procédé de la revendication 6, dans lequel l’approbation ou le refus (240, 415) de la transaction comporte le calcul (241) d’une deuxième signature numérique sur la base du premier CVV et d’un jeton de paiement par carte généré localement pour le titulaire de carte, et la comparaison (242) des première et deuxième signatures numériques.
  8. Procédé de l’une des revendications 1 à 7, dans lequel la transaction est refusée si le premier CVV est le même qu’un CVV utilisé au cours de l’une des dernières transactions.
  9. Procédé pour effectuer une transaction sans présence d’une carte, le procédé comprenant :
    l’entrée (305) d’un premier CVV dans un système marchand (20) connecté à un système de paiement (30), pour initier une transaction,
    l’entrée (315) d’une confirmation de transaction par l’utilisateur sur un dispositif du titulaire de carte (13) connecté au système de paiement (30), la confirmation de transaction par l’utilisateur étant basée sur un deuxième CVV, et
    la réception (325), par le biais du système marchand, d’une approbation ou d’un refus de la transaction en fonction des premier et deuxième CVV.
  10. Procédé de la revendication 9, dans lequel l’entrée de la confirmation de transaction par l’utilisateur comporte l’entrée du deuxième CVV sur le dispositif du titulaire de carte (13) ou la sélection du deuxième CVV dans une liste de CVV affichés sur le dispositif du titulaire de carte ou la confirmation d’un CVV affiché sur le dispositif du titulaire de carte comme étant le deuxième CVV.
  11. Procédé de la revendication 9 ou 10, dans lequel l’entrée (315) de la confirmation de transaction par l’utilisateur est en réponse à une demande d’autorisation de transaction par le système de paiement qui affiche les informations de la transaction sur le dispositif du titulaire de carte.
  12. Procédé de l’une des revendications 9 à 11, dans lequel le deuxième CVV est égal à une valeur attendue basée sur le premier CVV pour recevoir une approbation de la transaction.
  13. Procédé de l’une des revendications 9 à 12, comprenant en outre l’affichage préalable (300) d’informations de jeton de paiement par carte sur un écran du dispositif du titulaire de carte (13), dans lequel le premier CVV est entré (305) dans le système marchand (20) avec les informations affichées de jeton de paiement par carte.
  14. Système de paiement (30) qui traite une transaction sans présence d’une carte, le système de paiement comprenant :
    un serveur de réception des transactions (31) configuré pour recevoir une première valeur de vérification de carte, CVV, avec des informations de transaction provenant d’un système marchand (20),
    un serveur d’autorisation (32) configuré pour recevoir, d’un dispositif du titulaire de carte (13), une réponse d’autorisation de transaction qui est basée sur un deuxième CVV, et pour approuver ou refuser la transaction sur la base des premier et deuxième CVV.
  15. Système de titulaire de carte (10) comprenant un dispositif d’accès (12) à un système marchand (20) et un dispositif de titulaire de carte (13) connecté à un système de paiement (30), dans lequel :
    le dispositif d’accès (12) est configuré pour qu’un titulaire de carte entre un premier CVV dans le système marchand (20) pour initier une transaction,
    le dispositif du titulaire de carte (13) est configuré pour que le titulaire de carte entre une confirmation de transaction par l’utilisateur, la confirmation de transaction par l’utilisateur étant basée sur un deuxième CVV, et
    le dispositif d’accès (12) reçoit, par le biais du système marchand (20), une approbation ou un refus de la transaction en fonction des premier et deuxième CVV.
FR2010850A 2020-10-22 2020-10-22 Transactions sans présence de la carte avec une valeur de vérification de carte choisie par le titulaire de la carte Pending FR3115625A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
FR2010850A FR3115625A1 (fr) 2020-10-22 2020-10-22 Transactions sans présence de la carte avec une valeur de vérification de carte choisie par le titulaire de la carte
EP21203802.0A EP3989152A1 (fr) 2020-10-22 2021-10-20 Transactions sans présentation de carte avec cvv choisie par le détenteur de carte
US17/451,733 US20220129901A1 (en) 2020-10-22 2021-10-21 Card-not-present transactions with cardholder-chosen cvv

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2010850A FR3115625A1 (fr) 2020-10-22 2020-10-22 Transactions sans présence de la carte avec une valeur de vérification de carte choisie par le titulaire de la carte
FR2010850 2020-10-22

Publications (1)

Publication Number Publication Date
FR3115625A1 true FR3115625A1 (fr) 2022-04-29

Family

ID=74553943

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2010850A Pending FR3115625A1 (fr) 2020-10-22 2020-10-22 Transactions sans présence de la carte avec une valeur de vérification de carte choisie par le titulaire de la carte

Country Status (3)

Country Link
US (1) US20220129901A1 (fr)
EP (1) EP3989152A1 (fr)
FR (1) FR3115625A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170032369A1 (en) * 2015-07-31 2017-02-02 Gemalto, Inc. Method, device and first server for authorizing a transaction
US20180341944A1 (en) * 2012-12-21 2018-11-29 Sqwin Sa Online transaction system

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9195981B2 (en) * 2008-10-23 2015-11-24 Ims Health Incorporated System and method for authorizing transactions via mobile devices
US10304051B2 (en) * 2010-04-09 2019-05-28 Paypal, Inc. NFC mobile wallet processing systems and methods
EP2562704A1 (fr) * 2011-08-25 2013-02-27 TeliaSonera AB Procédé de paiement en ligne et élément de réseau, système et produit de programme informatique correspondant
TW201419185A (zh) * 2012-11-08 2014-05-16 Chien-Kang Yang 行動裝置、付款交易系統及付款交易方法
US11080777B2 (en) * 2014-03-31 2021-08-03 Monticello Enterprises LLC System and method for providing a social media shopping experience
US10579999B2 (en) * 2016-03-14 2020-03-03 Facebook, Inc. Network payment tokenization for processing payment transactions
WO2021030040A1 (fr) * 2019-08-09 2021-02-18 Critical Ideas, Inc. Dba Chipper Authentification par ussd

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180341944A1 (en) * 2012-12-21 2018-11-29 Sqwin Sa Online transaction system
US20170032369A1 (en) * 2015-07-31 2017-02-02 Gemalto, Inc. Method, device and first server for authorizing a transaction

Also Published As

Publication number Publication date
US20220129901A1 (en) 2022-04-28
EP3989152A1 (fr) 2022-04-27

Similar Documents

Publication Publication Date Title
EP3113099B1 (fr) Conteneur de paiement, procédé de création, procédé de traitement, dispositifs et programmes correspondants
CN107851254B (zh) 最大程度减少用户输入的无缝交易
US8074257B2 (en) Framework and technology to enable the portability of information cards
US20180082283A1 (en) Shared card payment system and process
RU2438172C2 (ru) Способ и система для осуществления двухфакторной аутентификации при транзакциях, связанных с заказами по почте и телефону
US20150294313A1 (en) Systems, apparatus and methods for improved authentication
US20160005038A1 (en) Enhanced user authentication platform
US20090281945A1 (en) Payment Processing Platform
EP3616111B1 (fr) Système et procédé permettant de générer des justificatifs d&#39;accès
US20190279196A1 (en) Systems and methods for digitizing payment card accounts
US20220318803A1 (en) Identity authentication systems and methods
FR3115625A1 (fr) Transactions sans présence de la carte avec une valeur de vérification de carte choisie par le titulaire de la carte
EP2824625B1 (fr) Méthode de réalisation de transaction, terminal et programme d&#39;ordinateur correspondant
EP4074005A1 (fr) Procede, serveur et systeme d&#39;authentification de transaction utilisant deux canaux de communication
US20180330366A1 (en) A transaction system and method of operating same
US20240152912A1 (en) Authentication system and method
WO2002046984A1 (fr) Procede securise de transaction entre un acheteur et un vendeur
EP1988483A2 (fr) Cadre et technologie pour permettre la portabilité des cartes d&#39;information
FR3011111A1 (fr) Securisation d&#39;une transmission de donnees d&#39;identification
WO2022136236A1 (fr) Procédé pour la création d&#39;un instrument de paiement au profit d&#39;un tiers bénéficiaire

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20220429

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4