FR3091945A1 - Procédé de transaction avec une devise différente, et dispositif correspondant - Google Patents

Abstract

Procédé de transaction avec une devise différente, et dispositif correspondant Procédé de contrôle mis en œuvre par un dispositif électronique au cours d’une transaction de paiement, la transaction de paiement étant associée à une devise, le procédé comprenant une vérification (S03) de la pertinence d’un taux de conversion de la devise associée à la transaction de paiement vers une devise associée au dispositif électronique. Figure pour l’abrégé : Fig. 2.

Description

Procédé de transaction avec une devise différente, et dispositif correspondant

L’invention se rapporte au domaine général des dispositifs électroniques configurés pour mettre en œuvre des transactions de paiement. L’invention concerne en particulier les dispositifs électroniques configurés pour mettre en œuvre des transactions de paiement.

L’invention trouve application de manière non exclusive dans les cartes à puce (ou cartes à microcircuit), conformes par exemple à la norme ISO 7816. L’invention concerne tout particulièrement les cartes à puce qui mettent en œuvre des transactions de paiement, par exemple selon le standard EMV (« Europay Mastercard Visa », par exemple dans sa version 4.3) et/ou la spécification EMV Contactless (par exemple dans sa version 3.0).

Le standard EMV, bien connu de l’homme du métier, est utilisé pour sécuriser des transactions réalisées par des cartes à puce, en particulier des transactions bancaires de paiement. D’autres transactions peuvent également être mises en œuvre par ces cartes à puce, par exemple des transactions de transfert, de consultation, ou encore d’authentification.

Ce standard permet de sécuriser les transactions et de limiter les fraudes. A cet effet, il implique l’utilisation de cryptogrammes ou encore de codes secrets (généralement désignés par l’acronyme anglo-saxon :« PIN : Personal Identification Number »).

Les cartes existantes sont généralement associées à une devise. Typiquement, une carte émise par une banque d’un pays de la zone euro sera associée à l’euro. Il reste cependant possible de mettre en œuvre des transactions dans d’autres devises. Les mécanismes de sécurité ou d’évaluation du risque de la carte, pour valider la transaction, vont alors convertir le montant de la transaction vers la devise associée à la carte pour ensuite utiliser ces mécanismes de sécurité ou d’évaluation du risque.

L’homme du métier désigne généralement ces mécanismes de sécurité ou d’évaluation du risque par l’acronyme anglo-saxon « CRM :Card Risk Management ». Le CRM comprend par exemple une comparaison entre une valeur limite de montant de transaction et le montant de la transaction en cours.

Dès lors, on comprend que les opérations de CRM ne peuvent être effectuées correctement que si la carte peut convertir la valeur du montant de la transaction en cours.

Les cartes comprennent donc typiquement une table dans lesquelles on peut lire, pour une devise (désignée par un code), un taux de conversion. Tel est notamment le cas pour les cartes qui implémentent la norme « Common Payment Application – EMV – Version 1.0 – Décembre 2015 ».

Généralement, les taux de conversion sont enregistrés dans les cartes au cours d’une phase de personnalisation bien connue de l’homme du métier.

Cette solution présente plusieurs problèmes. Tout d’abord, si certains taux de conversion sont fixes (tel est le cas entre le franc CFA et l’euro), d’autres sont dits flottants. Ces taux flottants peuvent donc être obsolètes et ne pas permettre de mettre en œuvre les opérations de CRM de manière satisfaisante.

Aussi, si un taux nécessaire est absent de la carte, certaines cartes peuvent accepter les transactions sans avoir pu faire les vérifications du CRM.

L’invention vise notamment à pallier ces inconvénients.

A cet effet, l’invention propose un procédé de contrôle mis en œuvre par un dispositif électronique au cours d’une transaction de paiement, la transaction de paiement étant associée à une devise, le procédé comprenant une vérification de la pertinence d’un taux de conversion de la devise associée à la transaction de paiement vers une devise associée au dispositif électronique.

Ainsi, dans l’invention, on va vérifier la pertinence du taux et tenir compte de cette information pour la suite de la transaction.

On pourra notamment mettre en œuvre un traitement qui tient compte de la pertinence ou de la non-pertinence du taux. Par exemple, ce traitement peut aboutir au refus de la transaction si le taux n’est plus pertinent.

On peut noter que la pertinence d’un taux peut être vérifiée par des comparaisons à des valeurs de seuil enregistrées dans le dispositif électronique.

Par exemple, un taux est pertinent si sa valeur est peu éloignée de celle réelle, ou au moins s’il est probable que la valeur du taux soit peu éloignée de celle réelle.

L’invention permet donc d’améliorer la sécurité des transactions, car la pertinence d’un taux est une information utile pour améliorer la sécurité de la transaction.

Selon un mode de réalisation particulier, le procédé comprend une vérification préalable de la présence dudit taux de conversion dans une mémoire non volatile du dispositif électronique.

Le procédé pourra comprendre un traitement supplémentaire tenant compte de l’absence du taux dans une mémoire non volatile du dispositif électronique. Par exemple, le traitement supplémentaire peut être un refus de la transaction.

On peut noter qu’un taux présent est enregistré. La vérification de sa présence peut utiliser un code qui désigne le taux.

Selon un mode de mise en œuvre particulier, le dispositif électronique émet une demande de taux de conversion si ledit taux de conversion n’est pas présent dans une mémoire non volatile du dispositif électronique.

On peut noter que cette émission d’une demande de taux peut être réalisée dans le cadre d’une transaction dans un mode dit en ligne (« online » en anglais).

Aussi, s’il a été déterminé que le taux n’est pas présent, le dispositif électronique peut forcer un mode en ligne pour la transaction. On peut noter que le mode en ligne peut également être forcé s’il est déterminé que le taux n’est pas pertinent.

Dans le cadre d’une transaction en ligne, il est possible, pour un dispositif électronique qui met en œuvre une transaction avec un lecteur configuré pour communiquer avec le dispositif électronique, d’émettre des informations au lecteur qui pourra les retransmettre à un tiers, typiquement à une entité émettrice du dispositif électronique (par exemple une banque si le dispositif électronique est une carte bancaire).

Selon un mode de mise en œuvre particulier, ladite vérification de la pertinence du taux est mise en œuvre au moyen d’au moins une information parmi une date de mise à jour du taux, un indicateur de volatilité du taux, et un type de taux. On pourra aussi utiliser toute combinaison de ces trois informations.

Les inventeurs de la présente invention ont observé que la date de mise à jour d’un taux est une information qui permet de vérifier si un taux est pertinent. Typiquement, si la durée (par exemple en nombre de jours) entre la date de mise à jour et la date actuelle est supérieur à un seuil prédéterminé, alors on considère que le taux n’est pas pertinent.

Un indicateur de volatilité peut indiquer la variation maximale possible d’un taux sur une base de temps. Typiquement, on pourra déterminer si la variation du taux depuis sa dernière mise à jour dépasse un seuil prédéterminé. Si tel est le cas le taux n’est pas pertinent.

En outre, le type de taux peut indiquer si le taux est un taux fixe ou un taux flottant. Si le taux est un taux fixe alors il est considéré comme pertinent. Si le taux est flottant alors des vérifications supplémentaires peuvent être mises en œuvre, éventuellement au moyen de la date de mise à jour du taux ou d’un indicateur de volatilité du taux.

Selon un mode de mise en œuvre particulier, si le taux de conversion de la devise associée à la transaction n’est pas pertinent alors on met à jour ledit taux de conversion.

Selon un mode de mise en œuvre particulier, la mise à jour dudit taux de conversion comprend l’émission d’une demande de taux de conversion.

Par exemple, l’émission de cette demande peut être réalisée au cours d’une transaction en ligne. Préférentiellement, si le taux n’est pas pertinent alors la transaction se poursuit dans un mode en ligne.

Selon un mode de mise en œuvre particulier, on convertit un montant associé à ladite transaction en utilisant ledit taux de conversion ou ledit taux de conversion mis à jour.

L’obtention de ce montant converti est particulièrement utile pour que la carte puisse déterminer si cette transaction peut être autorisée, par exemple.

Selon un mode de mise en œuvre particulier, ladite conversion comprend la détermination d’une plage de valeurs de montants convertis possibles en utilisant un indicateur de volatilité du taux.

Ce mode particulier de mise en œuvre peut en outre utiliser une date de mise à jour du taux.

La plage correspond à la variation croissante ou décroissante possible du taux à partir de son ancienne valeur.

Selon un mode de mise en œuvre particulier, on met en œuvre un traitement gestion du risque (c’est-à-dire un CRM) sur la base du montant converti ou sur la base de ladite plage de valeurs.

Si l’on utilise ladite plage de valeurs, on pourra par exemple tenir compte de la valeur maximale et/ou de la valeur minimale de la plage de valeurs pour le CRM.

Selon un mode de mise en œuvre particulier, la transaction est une transaction selon la norme EMV (Version 4.3, ou une version ultérieure), ou encore une transaction selon la norme EMV Contactless (Version 3.0, ou une version ultérieure).

L’invention propose également un dispositif électronique configuré pour mettre en œuvre une transaction de paiement associée à une devise, comprenant un module de vérification de la pertinence d’un taux de conversion de la devise associée à la transaction de paiement vers une devise associée au dispositif électronique.

Ce dispositif électronique peut être configuré pour la mise en œuvre de chacun des modes de mise en œuvre du procédé décrit ci-avant.

Selon un mode de réalisation particulier, le dispositif électronique comprend une carte à puce.

En particulier, la carte à puce peut être une carte à puce selon la norme ISO 7816 (version de 1999 ou ultérieure). Par exemple, la carte à puce peut être une carte bancaire.

L’invention propose également un programme d’ordinateur comportant des instructions pour l’exécution des étapes d’un procédé tel que défini ci-avant lorsque ledit programme est exécuté par un ordinateur.

A noter que les programmes d’ordinateur mentionnés dans le présent exposé peuvent utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.

L’invention propose également un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions pour l’exécution des étapes d’un procédé tel que défini ci-avant.

Les supports d’enregistrement (ou d’information) mentionnés dans le présent exposé peuvent être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur.

D'autre part, les supports d’enregistrement peuvent correspondre à un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.

Alternativement, les supports d’enregistrement peuvent correspondre à un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.

D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :

La figure 1 illustre de manière schématique les étapes d’un procédé de transaction selon un exemple.

La figure 2 illustre de manière schématique les étapes d’un CRM selon un exemple.

La figure 3 illustre de manière schématique les étapes d’un CRM selon un exemple.

La figure 4 est un schéma d’un exemple de dispositif électronique.

On va maintenant décrire un procédé de transaction de paiement mis en œuvre par un dispositif électronique selon un exemple d’implémentation de l’invention.

Dans cet exemple, le dispositif électronique est une carte à puce selon la norme ISO 7816. Cette carte à puce peut être capable de mettre en œuvre des transactions de paiement selon la norme EMV (Europay Mastercard Visa) dans sa version 4.3 et notamment au moyen d’applications, par exemple selon la norme d’implémentation d’applications « Common Payment Application – EMV – Version 1.0 – Décembre 2015 » (ou une version ultérieure). Cette carte à puce est ici une carte bancaire.

Dans l’exemple qui suit, la carte bancaire est munie d’une mémoire non-volatile qui comporte des informations qui vont faciliter la mise en œuvre du procédé.

Dans les cartes bancaires selon la technique antérieure on peut mémoriser uniquement des codes identifiant des taux de conversion, plusieurs taux associés à une même devise et chacun à une application respective , ainsi que des indicateurs qui indiquent la présence ou l’absence de chaque taux, et éventuellement des exposants de conversion (un nombre signé qui indique la puissance de 10 utilisée pour multiplier le taux de conversion mémorisé et obtenir une approximation du vrai taux). Ici, on mémorise davantage d’informations et notamment des informations choisies parmi :
- plusieurs taux associés à une même devise et chacun à un type de transaction effectuée sur la carte (paiement, retrait de liquide, paiement différé, remboursement, annulation …),
- les dates de dernière mise à jour des taux ;
- des indicateurs de volatilité pour chaque taux ;
- les types de chaque taux (fixe, flottant) ;
- un ou plusieurs seuils de comparaison pour vérifier si un taux n’est plus pertinent ; et
- un ou plusieurs seuils de comparaison pour vérifier si un taux de conversion n’est pas acceptable pour une transaction.

Avec une telle carte à puce, on peut mettre en œuvre des transactions de paiement telle que celle représentée sur la figure 1. Sur cette figure, on a représenté une transaction EMV.

Une transaction EMV peut commencer par la réception d’une commande de sélection d’application (étape select_app_RX). Cette commande est émise par un lecteur, par exemple un lecteur de carte bancaire d’un automate de distributeur de billets ou un terminal de paiement dans un magasin.

Au cours d’échanges avec le lecteur, la carte reçoit des informations relatives à la transaction et en particulier un montant et une devise (par exemple sous la forme d’un code qui désigne la devise) ; cette devise associée à la transaction peut être différente de la devise associée à la carte.

Ultérieurement et éventuellement après plusieurs échanges avec le lecteur, une commande de génération de cryptogramme, connue en soi dans une transaction EMV, est reçue au cours de l’étape generate_ac1_RX. Il s’agit de la première demande de génération de cryptogramme, qui va notamment permettre de déterminer si la transaction doit se poursuivre dans un mode en ligne ou dans un mode hors ligne.

A cet effet, on met en œuvre une étape de gestion du risque CRM_1 (typiquement un CRM), mais dans laquelle on met en œuvre une étape verif_1 de vérification de la pertinence d’un taux de conversion. En fonction des résultats de cette étape, la carte va élaborer un cryptogramme en réponse à la demande de l’étape generate_ac1_RX. Cette élaboration est donc mise en œuvre après l’étape CRM_1.

Ultérieurement et au cours de la même transaction, la carte à puce reçoit une deuxième demande de génération de cryptogramme dans l’étape generate_ac2_RX. Il s’agit de la deuxième demande de génération de cryptogramme, qui va notamment permettre de déterminer si la transaction est refusée ou acceptée.

A cet effet, on met en œuvre une étape de gestion du risque CRM_2 (typiquement un CRM), mais dans laquelle on met en œuvre une étape verif_2 de vérification de la pertinence d’un taux de conversion. En fonction des résultats de cette étape, la carte va élaborer un cryptogramme en réponse à la demande de l’étape generate_ac2_RX. Cette élaboration est donc mise en œuvre après l’étape CRM_2.

Les étapes CRM_1 et CRM_2 et leurs sous-étapes verif_1 et verif_2 vont être décrites plus en détail ci-après en référence aux figures 2 et 3.

Sur la figure 2, on a représenté des étapes qui peuvent être mises en œuvre dans le cadre du procédé de la figure 1, par exemple au cours de l’étape CRM_1 : la première étape de gestion du risque.

Dans une première étape S01, on vérifie si un taux de conversion permettant de passer de la devise associée à la transaction à la devise associée à la carte a été préalablement enregistré dans une mémoire non volatile de la carte. Un tel enregistrement peut avoir été fait au cours d’une phase de personnalisation. Par exemple, une table qui met en correspondance des codes associés aux devises et des taux peut être enregistrée dans la mémoire non volatile, et on peut consulter cette table au cours de l’étape S01.

Si le taux n’est pas présent, on met en œuvre l’étape S02 dans laquelle la carte émet une demande de taux de conversion. L’étape S02 peut comprendre le passage dans un mode en ligne pour la transaction.

Par exemple, la demande peut être émise à travers le lecteur à une entité émettrice de la carte, par exemple une banque.

Pour cette demande de mise à jour, la carte peut utiliser des informations de la carte qui vont indiquer l’application de paiement utilisée, ainsi que les informations relatives à l’absence de taux (et en particulier un identifiant du taux). Par exemple, on pourra utiliser les données connues de l’homme du métier sous l’acronyme anglo saxon « IDD : Issuer Discretionary Data » ou encore les données « CVR : Card Verification Result » (qui informent l’émetteur de la carte des conditions d’exception survenues lors de la transaction). Ces données sont typiquement stockées dans une partie appelée « IAD : Issuer Application Data ».

La table mentionnée ci-avant est ainsi complétée avec des informations reçues. On peut noter que la date de mise à jour du taux est également modifiée.

En outre, au cours de l’étape S02, on peut demander d’autres taux de conversion, par exemple d’autres taux qui ont été considérés comme non pertinents. A cet effet, dans une variante, on vérifie la pertinence de tout ou partie des taux de conversion mémorisés. Dans une autre variante, les autres taux ont été considérés comme non-pertinents au cours d’une transaction précédente (par exemple une transaction pour laquelle le mode en ligne n’était pas disponible).

Dans l’étape S03, on vérifie la pertinence du taux. On peut noter que si un taux a été reçu à l’étape S02, ce taux est considéré comme pertinent et la mise en œuvre de l’étape S03 est alors optionnelle. .

Selon une première variante, l’étape S03 comprend une détermination de la durée entre la date de mise à jour du taux et la date de la transaction en cours. Si cette durée est inférieure à un seuil de durée prédéterminé alors le taux de conversion est considéré comme pertinent.Selon une deuxième variante, l’étape S03 comprend la détermination d’une valeur possible maximale M_A_max pour le montant associé à la transaction et d’une valeur possible minimale M_A_min pour le montant associé à la transaction.

En fait, M_A_max et M_A_min peuvent être déterminés à partir d’un indicateur de volatilité du taux qui peut être exprimé en pourcentage de variation sur une durée prédéterminée (par exemple 30 jours), de la date de mise à jour, du montant de la transaction en cours exprimé dans la devise associée à la transaction, et le taux correspondant enregistré.

Par exemple, M_A_max = (1+VOL*DEL/BT)*M_X*T_XA, avec VOL l’indicateur de volatilité, DEL la durée entre la date de mise à jour et la date de transaction, BT la base de temps (typiquement 30 jours, M_X le montant exprimé dans la devise de la transaction en cours et T_XA le taux pour passer de la devise de la transaction en cours à la devise associée à la carte. Aussi, par exemple, M_A_min = (1-VOL*DEL/BT)*M_X*T_XA.

Si on a M_A_max-M_A_min>SEUIL1, avec SEUIL1 un seuil prédéfini, alors on considère qu’il y a trop d’incertitude sur le montant converti et le taux n’est pas pertinent.

Selon une troisième variante, si VOL*DEL/BT>SEUIL2, avec SEUIL2 un seuil prédéfini, alors on considère que la volatilité est trop grande et que le taux n’est pas pertinent.

D’autres variantes peuvent être conçues sur la base des valeurs VOL, DEL, etc.

On notera que dans l’étape S03, on peut également vérifier le type de taux. S’il est fixe, il est considéré comme pertinent.

S’il est déterminé que le taux n’est pas pertinent, alors on émet une demande de mise à jour du taux au cours dans l’étape S04. L’étape S04 peut comprendre le passage dans un mode en ligne pour la transaction. L’émission de cette demande est analogue à celle de l’étape S02 décrite ci-avant.

Au cours de l’étape S04, on peut demander d’autres taux de conversion, par exemple d’autres taux qui ont été considérés comme non pertinents. A cet effet, dans une variante, on vérifie la pertinence de tout ou partie des taux de conversion mémorisés. Dans une autre variante, les autres taux ont été considérés comme non-pertinents au cours d’une transaction précédente (par exemple une transaction pour laquelle le mode en ligne n’était pas disponible).

On peut noter que si une table est utilisée, alors la modification de cette table peut utiliser des commandes généralement désignées comme des « commandes de script » par l’homme du métier (dans la norme EMV, on parle de « Issuer Script Commands »). Cette commande peut identifier la table au moyen d’un identifiant, puis identifier le taux à mettre à jour par son identifiant. On peut également concevoir que si le taux à écrire (par exemple dans le cadre de l’étape S02) n’est pas présent dans la table, on peut écraser une autre valeur de taux (typiquement celle qui est la plus obsolète c’est-à-dire qui a la date de mise à jour la plus ancienne).

On met ensuite en œuvre l’étape S05 de conversion du montant de la transaction vers la devise.

Selon une première variante, on détermine une plage de valeurs de montants convertis possibles comprises entre M_A_max et M_A_min.

Selon une deuxième variante, on calcule directement un montant M_A= M_X*T_XA.

On peut ensuite mettre en œuvre l’étape S06 dans laquelle on met en œuvre un traitement de gestion du risque qui utilise les montants déterminés à l’étape S05.

Plusieurs vérifications peuvent être mises en œuvre. En particulier, si un seul montant M_A a été déterminé, on peut mettre à jour la valeur d’un accumulateur ACCU de montants de transactions réalisées avec la carte (On peut noter que différents accumulateurs de ce type peuvent être utilisés, par exemple un pour les transactions domestiques, un pour les transactions internationales, un pour les transactions de retrait, etc.). Si ACCU>LIMIT_UPPER, LIMIT_UPPER étant une limite supérieure alors on considère que cette vérification échoue et on en tient compte ensuite dans la réponse de la carte (généralement lors de la commande qui génère le cryptogramme). On peut aussi utiliser une limite inférieure LIMIT_LOWER et vérifier si ACCU>LIMIT_LOWER. De la même manière, on tient compte de l’échec de cette vérification dans la réponse de la carte.

Des comportements différents peuvent être associés au dépassement de LIMIT_LOWER et de LIMIT_UPPER, avec, comme on le conçoit, LIMIT_LOWER<LIMIT_UPPER.

Si une plage de montants possibles a été déterminée ([M_A_min ;M_A_max]), alors on peut utiliser et mettre à jour deux accumulateurs ACCU1=ACCU1+ M_A_max et ACCU2=ACCU2+ M_A_min.

Ensuite, dans une première variante, on peut vérifier si ACCU1>LIMIT_UPPER et si ACCU2>LIMIT_LOWER. On obtient ainsi une vérification plus précise qu’avec un unique accumulateur, qui tient compte de la volatilité du taux.

Dans une deuxième variante, on peut mettre en œuvre quatre vérifications :
- ACCU1>LIMIT_UPPER
- ACCU1>LIMIT_LOWER
- ACCU2>LIMIT_UPPER
- ACCU2>LIMIT_LOWER

Cette variante est plus précise que la première variante, et elle permet de prévoir des comportements différents en fonction de chaque dépassement détecté.

En outre, pour des applications, on peut avoir plusieurs limites inférieures et supérieures. Dans une troisième variante, les limites sont propres à chaque accumulateur, ce qui offre davantage de flexibilité.

L’initialisation des accumulateurs peut être effectuée durant la fabrication des cartes pendant une phase de personnalisation.

La réinitialisation de tout ou partie de ces accumulateurs peut se faire lors de la détection d’un évènement prédéterminé, par exemple la réception de la commande generate_ac2_RX décrite ci-avant (avec un paramètre spécifique), ou encore par des commandes de script telles qu’évoquées ci-avant.

La carte peut ensuite élaborer un cryptogramme, qui est le premier cryptogramme. Ce cryptogramme peut être élaboré à ce stade (c’est-à-dire après la mise en œuvre de l’étape S06), ou de manière alternative après la mise en œuvre de l’étape S02 ou de l’étape S04.

Sur la figure 3, on a représenté des étapes qui peuvent être mises en œuvre dans le cadre du procédé de la figure 1, par exemple au cours de l’étape CRM_2 : la deuxième étape de gestion du risque.

Ici, une première étape S10 est mise en œuvre de manière analogue à l’étape S01 décrite en référence à la figure 1. Si le taux est présent on met en œuvre l’étape S12 de vérification de la pertinence du taux (analogue à l’étape S03).

Par contre, si le taux n’est pas présent ou s’il n’est pas pertinent, on met en œuvre l’étape S11 de traitement de sécurité. Ce traitement peut comprendre :
- le refus de la transaction, car la banque considère que la transaction est trop risquée ; ou
- l’incrémentation d’un compteur de transactions pour lesquelles le taux est absent ou non pertinent.

L’utilisation du compteur de transactions pour lesquelles le taux est absent ou non pertinent permet de ne pas bloquer une transaction (ce qui a un impact sur l’utilisateur). Typiquement, dans un environnement où les transactions en ligne sont impossibles (par exemple un avion), on peut mettre en œuvre des transactions avec un taux qui n’est pas présent dans la carte mais le nombre de ces transactions peut être limité au moyen du compteur.

On met ensuite en œuvre les étapes S13 et S14 respectivement analogues aux étapes S05 et S06 de la figure 2.

Ici, le deuxième cryptogramme peut être élaboré à ce stade (c’est-à-dire après la mise en œuvre de l’étape S14), ou de manière alternative après la mise en œuvre de l’étape S11.

Sur la figure 4, on a représenté un dispositif électronique 100 de type carte bancaire. Le dispositif électronique 100 comprend notamment un processeur 101 (de manière alternative, plusieurs processeurs peuvent être utilisés), des moyens de communication 102 (comprenant typiquement des contacts selon la norme ISO 7816 et/ou une antenne radiofréquence pour une communication sans contact telle que détaillée dans la norme ISO/IEC 14443 ou NFC/ISO 15693), et une mémoire non volatile 103.

Dans la mémoire non volatile 103, des instructions de programme d’ordinateur INST sont mémorisées. Ces instructions permettent de mettre en œuvre les procédés tels que décrits ci-avant. En particulier, les instructions INST comprennent des instructions 104 pour vérifier la pertinence d’un taux de conversion au cours d’une transaction, ces instructions forment avec le processeur 101 un module de vérification de la pertinence d’un taux de conversion de la devise associée à la transaction de paiement vers une devise associée au dispositif électronique.

Le dispositif électronique comprend en outre une table 105 dans laquelle sont mémorisés des identifiants ou indicateurs de devises et des taux de conversion entre ces devises et la devise associée à la carte. En particulier, dans la table 105, on peut trouver une ou plusieurs informations choisies parmis :
- plusieurs taux associés à une même devise et chacun à un type de transaction effectuée sur la carte (paiement, retrait de liquide, paiement différé, remboursement, annulation …),
- les dates de dernière mise à jour des taux ;
- des indicateurs de volatilité pour chaque taux ;
- les types de chaque taux (fixe, flottant) ;
- un ou plusieurs seuils de comparaison pour vérifier si un taux n’est plus pertinent ; et
- un ou plusieurs seuils de comparaison pour vérifier si un taux de conversion n’est pas acceptable pour une transaction.

Claims (14)

1. Procédé de contrôle mis en œuvre par un dispositif électronique au cours d’une transaction de paiement, la transaction de paiement étant associée à une devise, le procédé comprenant une vérification (S03, S12) de la pertinence d’un taux de conversion de la devise associée à la transaction de paiement vers une devise associée au dispositif électronique.
2. Procédé selon la revendication 1, comprenant une vérification préalable (S01, S10) de la présence dudit taux de conversion dans une mémoire non volatile du dispositif électronique.
3. Procédé selon la revendication 2, dans lequel le dispositif électronique émet (S02) une demande de taux de conversion si ledit taux de conversion n’est pas présent dans une mémoire non volatile du dispositif électronique.
4. Procédé selon l’une des revendications 1 à 3, dans lequel ladite vérification de la pertinence du taux est mise en œuvre au moyen d’au moins une information parmi une date de mise à jour du taux, un indicateur de volatilité du taux (VOL), et un type de taux.
5. Procédé selon l’une quelconque des revendications 1 à 4, dans lequel si le taux de conversion de la devise associée à la transaction n’est pas pertinent alors on met à jour (S04) ledit taux de conversion.
6. Procédé selon la revendication 5, dans lequel la mise à jour dudit taux de conversion comprend l’émission d’une demande de taux de conversion.
7. Procédé selon l’une quelconque des revendications 1 à 6, dans lequel on convertit (S05, S13) un montant associé à ladite transaction en utilisant ledit taux de conversion ou ledit taux de conversion mis à jour.
8. Procédé selon la revendication 7, dans lequel ladite conversion comprend la détermination d’une plage de valeurs de montants convertis possibles en utilisant un indicateur de volatilité du taux.
9. Procédé selon la revendication 7 ou 8, dans lequel on met en œuvre un traitement gestion du risque (S06, S14) sur la base du montant converti ou sur la base de ladite plage de valeurs.
10. Procédé selon l’une quelconque des revendications 1 à 9, dans lequel la transaction est une transaction selon la norme EMV ou EMV contactless.
11. Dispositif électronique configuré pour mettre en œuvre une transaction de paiement associée à une devise, comprenant un module (101, 104) de vérification de la pertinence d’un taux de conversion de la devise associée à la transaction de paiement vers une devise associée au dispositif électronique.
12. Dispositif électronique selon la revendication 11, comprenant une carte à puce.
13. Programme d’ordinateur comportant des instructions pour l’exécution des étapes d’un procédé selon l’une quelconque des revendications 1 à 10, lorsque ledit programme est exécuté par un ordinateur.
14. Support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions pour l’exécution des étapes d’un procédé selon l’une quelconque des revendications 1 à 10.