FR3067499A1 - Controle de validite d'une interface de paiement a distance - Google Patents

Controle de validite d'une interface de paiement a distance Download PDF

Info

Publication number
FR3067499A1
FR3067499A1 FR1755832A FR1755832A FR3067499A1 FR 3067499 A1 FR3067499 A1 FR 3067499A1 FR 1755832 A FR1755832 A FR 1755832A FR 1755832 A FR1755832 A FR 1755832A FR 3067499 A1 FR3067499 A1 FR 3067499A1
Authority
FR
France
Prior art keywords
payment
user
data
transaction
historical
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
FR1755832A
Other languages
English (en)
Inventor
Eric Jacques Beaufils
Emmanuel Le Huerou
Francois Toutain
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Priority to FR1755832A priority Critical patent/FR3067499A1/fr
Priority to PCT/FR2018/000157 priority patent/WO2019002703A1/fr
Priority to EP18737653.8A priority patent/EP3646267A1/fr
Priority to US16/626,466 priority patent/US20200118134A1/en
Publication of FR3067499A1 publication Critical patent/FR3067499A1/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
    • 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/4016—Transaction verification involving fraud or risk level assessment in transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/16—Sound input; Sound output
    • G06F3/167—Audio in a user interface, e.g. using voice commands for navigating, audio feedback
    • 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/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or 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/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • 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
    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
    • G10L13/00—Speech synthesis; Text to speech systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Health & Medical Sciences (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Human Computer Interaction (AREA)
  • Multimedia (AREA)
  • General Health & Medical Sciences (AREA)
  • General Engineering & Computer Science (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Computational Linguistics (AREA)
  • Acoustics & Sound (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L invention se rapporte à un procédé de contrôle de validité d une interface de paiement à distance sur un terminal. Ce procédé est tel que, lors d une transaction de paiement entre un utilisateur et un site de paiement à distance, il comporte les étapes suivantes : - réception (E21) d au moins une donnée historique de transaction entre l utilisateur et le site de paiement ; - envoi (E23) d un code de validation de la transaction dans le cas où la au moins un donnée historique est vérifiée (E22) comme étant valide. Corrélativement, l invention se rapporte également à un procédé d envoi de données de validation d un site de paiement. Elle se rapporte également à un dispositif de contrôle et un serveur de paiement mettant en œuvre ces procédés respectifs.

Description

La présente invention se rapporte au domaine du paiement en ligne et des interfaces de paiement en ligne lors d'une transaction entre un utilisateur et un serveur de paiement sécurisé.
De façon particulière, on s'intéressera aux applications mobiles d'achat, de paiement, de commerce conversationnel via par exemple des interfaces de messagerie instantanée, ou bien de façon plus classique via une connexion à des sites Web marchand.
Lors d'une demande d'achat de produit ou de service entre un site marchand et un utilisateur d'un terminal, le site marchand fait appel à un site de paiement pour valider la transaction et récupérer le paiement.
Pour cela, le site de paiement demande à l'utilisateur de s'authentifier avant de valider le paiement. Il s'agit, pour le site de paiement, de vérifier que l'utilisateur est bien le possesseur du compte bancaire ou du compte de paiement.
Lors de l'inscription de l'utilisateur sur le site de paiement (par exemple lors de la création d'un compte « Orange cash » ou d'un compte « Paypal »), l'identité de l'utilisateur est vérifiée et est associée à un mot de passe ou un code de type code PIN (pour « Personnal Identification Number » en anglais) que l'utilisateur doit créer à cette occasion.
Lors du paiement, l'utilisateur est redirigé vers une interface du site de paiement et il doit prouver son identité par la saisie du mot de passe ou du code.
Si le site de paiement est capable de s'assurer de l'authentification de l'utilisateur de la transaction, il n'en est pas de même pour l'utilisateur qui n'a pas de moyen efficace pour s'assurer de la validité de l'interface de paiement qui lui est proposé.
En effet, avant d'entrer son code PIN ou bien son mot de passe, il peut être utile de s'assurer que ces informations ne tomberont pas aux mains de faussaires malveillants.
A l'heure actuelle, une façon de vérifier que l'interface de paiement est valide, lorsque cette interface est ouverte sur un navigateur, est de vérifier que le protocole utilisé est bien un protocole sécurisé « https » certifiant la validité du nom du domaine sur lequel est hébergé l'interface de paiement. Cette information du nom de domaine est affichée sur l'interface et est associée à une illustration sous la forme d'un cadenas fermé sur l'interface de navigation.
Cependant, il existe différentes possibilités de tromper l'utilisateur d'une telle interface. Cette illustration de cadenas n'est pas très visible et l'utilisateur ne remarque pas nécessairement qu'elle n'est pas présente.
Dans le cas où l'utilisateur est dirigé vers un faux site de paiement, le faussaire peut prévoir sur son interface falsifiée, l'illustration d'un même cadenas et ainsi tromper l'utilisateur qui ne sait pas nécessairement reconnaître un nom de domaine valide d'un autre falsifié, surtout s'ils sont volontairement ressemblants.
Dans le cas d'une interface mobile de paiement, la taille de l'écran étant limitée, il n'est pas toujours prévu d'afficher ce nom de domaine et cette certification de nom de domaine.
De plus, dans le cas de transactions initiées par des services de commerce conversationnel, via des interfaces de messagerie instantanée, par exemple, ces certifications Web ne sont pas prévues sur l'interface de paiement proposée à l'utilisateur. Celui-ci n'a donc pas de moyen de vérification de la validité de l'interface de paiement.
Il existe donc un besoin, pour l'utilisateur d'une interface de paiement, lors d'une transaction, de vérifier la validité de l'interface de paiement avant de valider le paiement par l'entrée de ses données personnelles d'authentification.
La présente invention vient améliorer la situation.
Elle propose à cet effet, un procédé de contrôle de validité d'une interface de paiement à distance sur un terminal. Le procédé est tel que, lors d'une transaction de paiement entre un utilisateur et un site de paiement à distance, il comporte les étapes suivantes :
- réception d'au moins une donnée historique de transaction entre l'utilisateur et le site de paiement ;
- envoi d'un code de validation de la transaction dans le cas où la au moins un donnée historique est vérifiée comme étant valide.
Ainsi, les données historiques de transaction de l'utilisateur avec le site de paiement permettent à l'utilisateur ou au terminal de l'utilisateur de s'assurer que le site de paiement est bien un site de paiement que l'utilisateur a déjà utilisé pour des transactions passées. Ce site de paiement n'est donc pas frauduleux et l'utilisateur peut alors insérer son code de validation de paiement en toute confiance.
Les différents modes particuliers de réalisation mentionnés ci-après peuvent être ajoutés indépendamment ou en combinaison les uns avec les autres, aux étapes du procédé de contrôle défini ci-dessus.
Dans un mode de réalisation particulier, la au moins une donnée historique reçue est affichée sur une interface de paiement comprenant une demande de code de validation.
Ainsi, juste avant de rentrer son code de validation de paiement, l'utilisateur peut vérifier que les informations historiques sont valides. L'affichage sur une même interface de la demande de code et des données historiques assure l'utilisateur que c'est bien le même serveur qui envoie ces deux informations. Les données historiques affichées correspondent bien au site de paiement qui demande le code de validation.
De même, de façon à alerter l'utilisateur de l'importance des données affichées, l'affichage de la au moins une donnée historique est associé à l'affichage d'une information de mise en garde de l'utilisateur en cas de non validité de la au moins une donnée historique.
Dans un mode de réalisation particulier, la au moins une donnée historique est restituée vocalement à l'utilisateur via une interface vocale du terminal.
Dans un mode de réalisation possible, la au moins une donnée historique comporte des données de date et de montant de la dernière transaction ou de plusieurs dernières transactions ou encore une adresse de livraison de l'utilisateur.
Ces données permettent d'identifier de façon simple les transactions passées ou le lien que le site de paiement a déjà eu avec l'utilisateur.
Bien évidemment, toutes autres informations sur des transactions passées peuvent être retrouvées et obtenues par le terminal pour vérifier leur validité avant validation du paiement.
Dans un mode de réalisation particulier, la vérification que la au moins une donnée historique est valide, comprend une étape de comparaison de données de transactions mémorisées dans le terminal et d'affichage d'un message de validation de la vérification sur une interface de paiement.
Cette étape est alors effectuée de façon automatique par le terminal qui contient en mémoire les données de transactions passées avec un ou plusieurs sites de paiement. Le terminal recevant les données historiques peut alors comparer en fonction du site de paiement, si les informations reçues sont bien celles mémorisées et peut alors afficher un message à l'utilisateur confirmant la validité des informations reçues, afin que celui-ci puisse rentrer le code de validation de paiement en toute confiance.
Dans un autre mode de réalisation, la vérification que la au moins une donnée historique est valide est effectuée par l'utilisateur par la visualisation des données historiques affichées ou par l'écoute des données historiques restituées, avant une étape d'interaction avec l'interface de paiement pour entrer des données de validation de la transaction.
L'utilisateur doit alors se rappeler des dernières transactions qu'il a effectuées avec le site de paiement. S'il ne reconnaît pas la ou les données historiques qui sont affichées alors il ne rentre pas le code de validation de paiement et la transaction échoue.
Corrélativement, l'invention vise également un procédé d'envoi de données de validation d'un site de paiement vers un terminal. Le procédé est tel que, lors d'une transaction de paiement entre l'utilisateur du terminal et le site de paiement, il comporte les étapes suivantes :
- obtention de données historiques de transaction entre l'utilisateur et le site de paiement ;
- envoi d'au moins une donnée historique obtenue au terminal ;
- attente de réception d'un code de validation de la transaction de l'utilisateur du terminal avant de valider le paiement, la réception du code de validation étant conditionnée à la vérification de validité de la au moins une donnée historique envoyée.
Le serveur de paiement retrouve ainsi les données historiques de transactions déjà passées entre lui et l'utilisateur qui souhaite valider le paiement. Par l'envoi de ces informations au terminal de l'utilisateur, il permet à celui-ci de vérifier que ce site n'est pas un site frauduleux. La transaction pourra ainsi être finalisée par la réception du code de validation de l'utilisateur.
Dans un mode de réalisation particulier, la au moins une donnée historique est envoyée avec une interface de paiement comportant une demande de code de validation de la transaction.
L'envoi simultanée de l'interface de la demande de code et des données historiques permet d'assurer l'utilisateur que c'est bien le même serveur qui envoie ces deux informations. Les données historiques envoyées au terminal de l'utilisateur correspondent donc bien au site de paiement qui demande le code de validation. A la réception de ces deux informations, l'utilisateur pourra vérifier la validité des données historiques et pourra saisir le code de validation du paiement.
L'invention vise un dispositif de contrôle de validité d'une interface de paiement à distance. Ce dispositif comporte un circuit de traitement comportant un processeur et étant apte à contrôler:
- un module d'affichage d'une interface de transaction de paiement lors d'une transaction de paiement entre un utilisateur et un site de paiement à distance ;
- un module de communication apte à recevoir au moins une donnée historique de transaction entre l'utilisateur et le site de paiement et à envoyer un code de validation de la transaction via une interaction avec l'interface de paiement, dans le cas où la au moins une donnée historique est vérifiée comme valide.
L'invention se rapporte également à un terminal de communication comportant un dispositif tel que décrit.
Le dispositif et le terminal ainsi décrits comportent les mêmes avantages que le procédé de contrôle décrit qu'ils mettent en œuvre.
Corrélativement, l'invention vise un serveur d'un site de paiement. Ce serveur, comporte un circuit de traitement comportant un processeur et étant apte à contrôler lors d'une transaction de paiement entre un utilisateur et le site de paiement :
- une mémoire comportant des données historiques de transaction entre l'utilisateur et le site de paiement et un module d'obtention d'au moins une de ces données ;
- un module de communication apte à envoyer au terminal la au moins une donnée historique obtenue et à recevoir un code de validation de la transaction de l'utilisateur du terminal, la réception du code de validation étant conditionnée à la vérification de validité de la au moins donnée historique envoyée;
- un module de validation du paiement après vérification du code de validation.
Le serveur ainsi décrit comporte les mêmes avantages que le procédé d'envoi de données de validation décrit qu'il met en œuvre.
L'invention vise un programme informatique comportant des instructions de code pour la mise en œuvre des étapes du procédé de contrôle de validité d'une interface de paiement à distance tel que décrit précédemment ainsi qu'un programme informatique comportant des instructions de code pour la mise en œuvre des étapes du procédé d'envoi de données de validation d'un site de paiement tel que décrit, lorsque ces instructions sont exécutées par un processeur.
Enfin l'invention se rapporte à un support de stockage, lisible par un processeur, mémorisant un programme informatique mettant en œuvre un procédé de contrôle de validité d'une interface de paiement à distance tel que décrit précédemment, ainsi qu'un programme informatique mettant en œuvre un procédé de d'envoi de données de validation d'un site de paiement tel que décrit précédemment.
Le support de stockage peut ê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, un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur. D'autre part, le support de stockage peut être 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, le support de stockage peut être 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 l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée uniquement à titre d'exemple non limitatif, et faite en référence aux dessins annexés, sur lesquels :
- la figure 1 illustre un système comportant notamment un terminal et un serveur de paiement mettant en œuvre l'invention dans un mode de réalisation ;
- la figure 2 illustre sous forme d'organigramme les principales étapes d'un mode de réalisation d'un procédé de contrôle de validité d'une interface de paiement mis en œuvre par le terminal et d'un procédé d'envoi de données de validation mis en œuvre par un serveur de paiement ;
- les figures 3a, 3b et 3c illustrent des interfaces de paiement affichés sur un terminal dans des modes de réalisation particuliers de l'invention ;
- la figure 4 illustre schématiquement une représentation matérielle d'un terminal comportant un dispositif de contrôle de validité et mettant en œuvre un procédé de contrôle de validité selon un mode de réalisation de l'invention ; et
- la figure 5 illustre une représentation matérielle d'un serveur de paiement mettant en œuvre un procédé d'envoi de données de validation selon un mode de réalisation de l'invention.
On se réfère tout d'abord à la figure 1 sur laquelle on a représenté un terminal de communication TA. Le terminal TA, ici représenté par un terminal mobile, comporte une interface de communication pour communiquer vers le réseau R où sont représentés deux serveurs, un serveur marchand SM hébergeant un site marchand proposant à l'achat des produits ou services et un serveur de paiement apte à recevoir des ordres de paiement pour les produits ou services demandés et à valider ces paiements auprès des banques concernées ou plus généralement auprès d'un compte de paiement, le compte de paiement pouvant être hébergé chez un tiers de paiement n'offrant pas nécessairement de service bancaires.
Dans un mode particulier de réalisation, le serveur marchand et le serveur de paiement peuvent être confondus.
Le réseau R est un réseau de communication, par exemple de type IMS, qui permet l'établissement de communications entre des terminaux et des serveurs tels que représenté ici. Le terminal TA peut communiquer vers les serveurs SM ou SP via un service de commerce conversationnel basé sur une application de messagerie instantanée enrichie, installée sur le terminal et qui permet d'échanger avec un robot adapté au site marchand, par exemple, pour commander des biens ou des services. Les utilisateurs de telles applications de messagerie instantanée enrichie, n'ont alors plus besoin de télécharger des applications dédiées à chaque site marchand ou d'accéder à leur site Web pour passer commande.
Des boutons d'actions ou des liens hypertextes peuvent également être prévus sur l'interface de commerce conversationnel pour déclencher une action d'achat ou bien de consultation de pages web.
L'invention n'est pas limitée au cadre des réseaux IMS. Le réseau de communication R peut être un réseau de télécommunication GSM (Global System for Mobile communication) permettant l'établissement de communications vocales et l'échange de messages textuels par le biais de SMS (short Message Service) par exemple. Le réseau R est par exemple aussi le réseau internet auquel le terminal TA peut se connecter pour échanger des données et accéder, entre autre, aux pages web du site marchand et effectuer ses commandes.
Le réseau R peut également correspondre à plusieurs réseaux distincts et interconnectés à partir desquels les serveurs SM et SP sont accessibles. Par exemple, le terminal TA peut établir des communications vocales par l'intermédiaire d'un réseau fixe commuté ou un réseau cellulaire et des communications textuelles ou échange de données via un réseau d'accès WiFi, 2G, 3G ou 4G.
Le terminal TA est ici un téléphone mobile de type « smartphone » disposant de moyens de communications adaptés pour se connecter à un ou plusieurs réseaux de communication, tels que des réseaux Wifi ou des réseaux cellulaires, ainsi que d'une mémoire et d'un processeur adaptés pour exécuter des instructions de programme d'ordinateur. L'invention décrite ci-après peut toutefois être mise en œuvre sur d'autres terminaux, tels que sur une tablette, un objet connecté, un tableau de bord de véhicule ou encore un ordinateur personnel. Le terminal TA est par exemple adapté pour communiquer selon au moins un protocole de messagerie instantanée avec d'autres terminaux ou dispositifs. Par exemple, le terminal TA peut émettre et recevoir des messages de type SMS (Short Message Service) par l'intermédiaire d'un réseau cellulaire, ou encore mettre en œuvre le standard RCS (Rich Communication Suite), le protocole SIP SIMPLE, Jabber ou tout autre protocole adapté pour envoyer et recevoir des messages. En particulier, le terminal TA peut échanger des messages instantanés avec le serveur SM au travers du réseau R.
La figure 2 représente les étapes (E20 à E23) d'un procédé de contrôle de validité d'une interface de paiement mises en œuvre dans le terminal TA, dans un mode de réalisation, ainsi que les étapes (E27 à E33) d'un procédé d'envoi de données de validation d'un site de paiement mises en œuvre, par exemple, dans un serveur de paiement SP.
La figure 2 représente aussi les étapes mises en œuvre sur un serveur marchand SM proposant des produits ou services à l'utilisateur du terminal TA. Ce serveur marchand peut être également un agent (ou robot) conversationnel permettant de proposer à l'utilisateur des biens ou services de différents marchands par l'intermédiaire d'une messagerie instantanée.
Dans un mode possible de réalisation, le serveur marchand et le serveur de paiement peuvent être un seul et même serveur.
A l'étape E20, l'utilisateur du terminal TA, après consultation d'un site Web du site marchand ou bien après échange d'une conversation par messagerie instantanée proposant l'achat de service ou de produit, décide de valider une commande en validant la création d'un panier par exemple.
Il effectue en E20 une commande, qu'il transmet au serveur SM pour qu'il la valide et déclenche l'envoi d'un ordre de paiement. Le serveur du site marchand, SM, reçoit cette commande en E24 et transmet l'ordre de paiement à un serveur de paiement SP pour que celui-ci interagisse avec l'utilisateur du terminal TA pour valider le paiement.
Le serveur de paiement reçoit cet ordre de paiement en E27.
Dans une variante de réalisation de ces étapes d'échange, par exemple pour une application de commerce conversationnel installée sur le terminal TA, lors de la validation d'une commande par l'utilisateur du terminal, celui-ci peut recevoir, en provenance de l'agent conversationnel du serveur SM, un lien ou bouton d'action qui lui permet de payer et le met en relation directement avec le serveur de paiement. Ce bouton d'action, lorsque l'utilisateur du terminal l'actionne, met en œuvre une application permettant d'échanger les identifiants à la fois de l'utilisateur du terminal TA et du site marchand ainsi que les informations sur la transaction demandée pour la commande en cours.
Le serveur de paiement, SP, recevant cet ordre de paiement en E27, consulte une base de donnée interne ou externe dans laquelle sont stockées des informations des dernières transactions réalisées en correspondance avec un identifiant de l'émetteur de la commande.
A l'étape E28, le serveur de paiement consulte donc dans sa base de données et obtient les données de transaction passées correspondant à l'identifiant de l'utilisateur qui a émis la commande pour cet ordre de paiement.
Il envoie au moins une de ces données historiques au terminal TA (étape
E29).
Ces données historiques sont par exemple, la date et le montant du dernier ou bien des 2 ou 3 derniers paiements que l'utilisateur a effectués sur ce site de paiement. Il peut y voir également le nom du site marchand correspondant.
Une autre donnée peut être l'adresse de livraison utilisée pour les derniers achats et transactions effectués par cet utilisateur.
Toute information liée à l'utilisateur et aux dernières transactions peut être ainsi retrouvée et envoyée au terminal pour validation.
Ces données historiques sont des données multimédia, elles peuvent être sous la forme de texte, d'image ou de son et toujours relatives à l'utilisateur.
Bien entendu, les données historiques de transaction ainsi décrites, n'existent que si l'utilisateur a déjà effectué un paiement via ce site de paiement.
Dans le cas où aucune transaction passée n'a été effectuée avec le serveur de paiement, une donnée personnelle de l'utilisateur peut alors être envoyée comme donnée historique. Cette donnée personnelle a par exemple été enregistrée sur le serveur lorsque l'utilisateur a créé son compte auprès du serveur de paiement. Il peut s'agir d'une réponse à une question personnelle ou bien une information personnelle sur son identité.
En E21, le terminal TA reçoit ces données historiques des transactions passées avec le site de paiement.
Ces données historiques sont, dans un mode de réalisation, affichées sur l'interface de paiement et sur l'écran du terminal.
Dans un autre mode de réalisation, elles sont restituées vocalement à l'utilisateur via une interface vocale du terminal.
Elles peuvent être affichées ou restituées simultanément avec une demande d'entrée d'un code de validation du paiement sur l'interface de paiement.
Ainsi, juste avant de rentrer son code de validation de paiement, l'utilisateur peut vérifier que les informations historiques sont valides. L'affichage sur une même interface de la demande de code et des données historiques assure l'utilisateur que c'est bien le même serveur qui envoie ces deux informations. Les données historiques affichées correspondent bien au site de paiement qui demande le code de validation.
Dans un mode de réalisation particulier, et de façon à alerter l'utilisateur de l'importance des données affichées, l'affichage des données historiques est associé à l'affichage d'une information de mise en garde de l'utilisateur en cas de non validité de ces données historiques.
Une étape E22 de vérification de la validité de ces données est effectuée. Cette étape est, dans un mode de réalisation possible, effectuée par l'utilisateur luimême, par la visualisation sur l'interface de paiement des données historiques de transactions affichées ou par l'écoute des données historiques restituées. L'utilisateur s'assure alors que le site de paiement est bien un site de paiement que l'utilisateur a déjà utilisé pour des transactions passées. Ce site de paiement n'est donc pas frauduleux et l'utilisateur peut alors insérer son code de validation de paiement en toute confiance en interagissant avec l'interface de paiement pour entrer ses données de validation de la transaction.
Dans un autre mode de réalisation, l'utilisateur peut demander au serveur de paiement une autre information historique en réponse à ce premier envoi, dans le cas où il n'est pas sûr de pouvoir valider ces premières données.
L'interface peut ainsi prévoir un bouton d'action déclenchant la demande d'une autre donnée au serveur.
Le serveur de paiement récupère ainsi au moins une autre donnée historique qui concerne l'utilisateur et effectue un deuxième envoi de ces données à l'utilisateur.
Un nombre limité de demandes successives peut être prévu. Passé ce nombre, la transaction est automatiquement annulée.
Lorsque les données de validation ont été entrées, elles sont ensuite envoyées au serveur de paiement SP à l'étape E23.
Dans un autre mode de réalisation, l'étape E22 de vérification, que les données historiques sont valides, comprend une étape de comparaison de données de transactions mémorisées dans le terminal et d'affichage d'un message de validation de la vérification sur l'interface de paiement.
Ces étapes sont effectuées alors par le terminal lui-même qui a enregistré en mémoire les dernières données de transaction et qui peut ainsi les comparer avec les données historiques reçues. Pour cela, le terminal met en oeuvre cette étape via par exemple son système d'exploitation interne ou bien dans un mode de réalisation particulier et dans le cas de la mise en œuvre de commerce conversationnel, via la plateforme logicielle de messagerie instantanée.
Cette comparaison est effectuée avant l'affichage de demande de code de validation sur l'interface de paiement. Cet affichage est alors accompagné d'un message confirmant que le terminal a bien vérifié les données historiques qu'il a reçues. L'utilisateur peut alors en toute confiance, saisir son code de validation.
Dans le cas où les données historiques sont considérées comme non valides, alors la transaction échoue, l'utilisateur ne rentrant pas son code de validation.
Lorsque le serveur de paiement reçoit le code de validation en E30, il vérifie en E31 que ce code de validation correspond bien aux données d'authentification de l'utilisateur pour cette commande et valide la transaction lorsque cette vérification est positive. Dans le cas contraire, la transaction échoue.
Une information de validation du paiement peut alors être envoyée en E33 au serveur marchand SM qui la reçoit en E26 pour ensuite délivrer la commande de l'utilisateur.
Un exemple d'interface de paiement reçue sur le terminal TA est illustré aux figures 3a à 3c. La figure 3a montre une interface de paiement auprès d'un serveur de paiement « Orange Cash », affichée sur le terminal d'un utilisateur qui a effectué une commande auprès d'un marchand M3 dont l'adresse est affichée. Le numéro de commande est également affiché ainsi que le montant associé. Le compte de l'utilisateur qui va permettre d'effectuer le paiement est aussi affiché. Pour effectuer le paiement, l'utilisateur actionne le bouton « payer » sur cette interface. S'il annule cette commande, il actionne le bouton « annuler ».
L'action sur le bouton « payer » permet le déclenchement du procédé de contrôle de validité de l'interface de paiement sur le terminal ainsi que la mise en œuvre du procédé correspondant d'envoi de données de validation sur le serveur de paiement.
Le serveur de paiement consulte sa base de données pour retrouver les dernières données de transactions que l'utilisateur a eues avec ce site de paiement.
Ces données sont envoyées au terminal qui les affiche selon un exemple illustré en figure 3b.
On voit en effet que les deux dernières transactions sont affichées, une première ayant été effectuée le 25.05.2017 chez le marchand Ml pour un montant de 10,87€ et la deuxième ayant été effectuée le 03.06.2017 chez le marchand M2 pour un montant de 53€.
Ces données peuvent être accompagnées d'un premier message explicatif (MESS 1) du type « Vérifiez que vous pouvez valider les informations ci-dessous avant de valider le paiement ».
Un message de mise en garde peut également être affiché (MESS 2) du type « Si ces informations ne sont pas les vôtres ou ne vous correspondent pas, NE SAISISSEZ PAS VOTRE CODE PIN ».
La saisie du code PIN en question peut alors se faire dans les carrés prévus à cet effet sur l'interface.
Avec cette interface, c'est à l'utilisateur lui-même d'effectuer la vérification des données historiques. Il doit se rappeler des dernières données de transactions qu'il a effectuées avec ce site de paiement pour entrer son code PIN et ainsi valider le paiement.
Dans un autre mode de réalisation où la vérification de la validité des données historiques envoyées est effectuée de façon automatique par le terminal, l'interface de paiement peut être un peu différente comme illustrée à la figure 3c.
Ici, un message MESS 3 peut informer que le terminal a bien effectué sa vérification. Ce message peut être du type « Les données historiques des dernières transactions reçues et affichées ci-dessous ont bien été validées ».
Et un message «MESS 4 » peut confirmer que l'utilisateur peut entrer son code PIN en toute confiance. Ce message peut être du type « Le site de paiement est valide, vous pouvez entrer votre code PIN en toute confiance ».
Les données historiques peuvent ne pas être affichées dans ce mode de réalisation puisque c'est le terminal qui effectue la vérification avec les données qu'il a en mémoire. Dans ce cas, le message MESS 3 ne comporte pas les mots « et affichées ci-dessous ».
Si les données sont également affichées, comme illustré en figure 3c, alors une double vérification peut être effectuée, par le terminal et par l'utilisateur avant qu'il n'entre le code PIN demandé.
Dans une variante de réalisation, les interfaces visuelles ainsi représentées peuvent être transformées en interfaces vocales. Les données historiques reçues sont ainsi vocalisées ainsi que les messages les accompagnant. De même, l'interface de paiement peut être une interface vocale dans laquelle il est demandé à l'utilisateur d'entrer vocalement son code de validation de paiement après qu'il ait vérifié les données historiques.
De la même façon, ces interfaces peuvent être constituées d'une partie vocale, par exemple les données historiques reçues et restituée vocalement et d'une partie visuelle, par exemple l'interface de paiement, l'entrée du code de validation par l'utilisateur s'effectuant alors par un clavier tactile ou non du terminal.
La figure 4 illustre à présent une représentation matérielle d'un dispositif de contrôle de validité d'une interface de paiement à distance TA selon un mode de réalisation de l'invention. Ce dispositif peut être intégré à un terminal de communication par exemple terminal de communication mobile, de type « smartphone », ordinateur, tablette, objet connecté ou autre équipement.
Ce dispositif met en œuvre le procédé de contrôle de validité d'une interface de paiement décrit en référence à la figure 2 par les étapes principales E20 à E23.
Matériellement, ce dispositif TA comporte un circuit de traitement 42 comportant un processeur et coopérant avec un bloc mémoire BM comportant une mémoire de stockage et/ou de travail MEM.
Le processeur pilote des modules de traitement aptes à mettre en œuvre le procédé de contrôle de validité décrit en référence à la figure 2.
Le terme module peut correspondre aussi bien à un composant logiciel qu'à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sousprogrammes d'ordinateur ou de manière plus générale à tout élément d'un programme apte à mettre en oeuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en oeuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.)
Le bloc mémoire peut avantageusement comporter un programme informatique (progl.) comportant des instructions de code pour la mise en oeuvre des étapes du procédé de contrôle de validité d'une interface de paiement à distance au sens de l'invention, lorsque ces instructions sont exécutées par le processeur PROC et notamment, lors d'une transaction de paiement entre un utilisateur et un site de paiement à distance, les étapes de réception d'au moins une donnée historique de transaction entre l'utilisateur et le site de paiement et d'envoi d'un code de validation de la transaction dans le cas où la au moins un donnée historique est vérifiée comme étant valide.
Ce programme peut 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'initialisation, les instructions du programme d'ordinateur (prog.l) sont par exemple chargées dans une mémoire RAM (Random Access Memory en anglais) avant d'être exécutées par le processeur de l'unité de traitement 42. Le processeur de l'unité de traitement 42 met en œuvre les étapes du procédé de contrôle tel que décrit selon les instructions du programme d'ordinateur.
Typiquement, la description de la figure 2 reprend les étapes d'un algorithme d'un tel programme informatique. Le programme informatique peut également être stocké sur un support mémoire lisible par un lecteur du dispositif ou téléchargeable dans l'espace mémoire de celui-ci.
La mémoire MEM enregistre de manière générale, toutes les données nécessaires à la mise en œuvre du procédé de contrôle et notamment, dans un mode de réalisation du procédé de contrôle, des données concernant les dernières transactions passées en correspondance avec les sites de paiement concernés.
Le dispositif possède également un écran 43 apte à afficher les interfaces de commande et les interfaces de transaction de paiement. L'écran est ainsi apte à afficher les données historiques de transaction reçues d'un serveur de paiement et d'afficher simultanément une demande de saisie de code de validation de paiement.
Des exemples de telles interfaces sont illustrés en référence aux figures 3a à 3c.
Le dispositif comporte également une interface utilisateur 44 (par exemple une interface tactile sur l'écran ou bien une interface de type clavier physique) permettant à l'utilisateur d'interagir lors d'une commande ou d'un paiement, par exemple en saisissant un code de validation de paiement dans le cas où les données historiques de transaction ont été vérifiées comme valides.
L'interface utilisateur 44 peut également, dans un mode de réalisation, être une interface vocale qui traduit les messages reçus et en particulier les données historiques reçues, en message vocaux via des moyens de restitution vocale de type haut-parleurs non représentés ici.
De même, cette interface vocale permet de recevoir des messages vocaux de l'utilisateur via des moyens de captation du son tels que des microphones non représentés ici.
Le dispositif TA comprend aussi un module de communication apte à recevoir une ou plusieurs données historiques de transaction entre l'utilisateur et le site de paiement et à envoyer un code de validation de la transaction via une interaction avec l'interface utilisateur 44 et l'interface de paiement affichée, dans le cas où les données historiques de transaction ont été vérifiées comme valides.
Ce module de communication 41 est par exemple une interface réseau COM (par exemple une interface WiFi, 3G, 4G ou ethernet), permettant au dispositif de se connecter à un réseau de télécommunication R et d'échanger des données avec d'autres dispositifs ou des serveurs de type serveur marchand et serveur de paiement, par l'intermédiaire du réseau de télécommunications. Ce module de communication permet en particulier d'échanger des messages avec un agent conversationnel dans le cas d'une mise en œuvre par commerce conversationnel.
La figure 5 illustre à présent une représentation matérielle d'un dispositif SP d'envoi de données de validation d'un site de paiement selon un mode de réalisation de l'invention. Ce dispositif peut être intégré à un serveur de paiement dans un réseau de communication.
Ce dispositif met en œuvre le procédé d'envoi de données de validation d'un site de paiement décrit en référence à la figure 2 par les étapes principales E27 à E33.
Il possède un module de communication 51 permettant de communiquer avec d'autres équipements du réseau de communication, par exemple avec le terminal TA.
Le module de communication 51 peut être par exemple une interface réseau WïFi, 3G, 4G ou encore une interface Ethernet et permet au dispositif de transmettre des messages vers le terminal TA ou vers un autre serveur du réseau, par exemple un serveur marchand SM. Il permet d'envoyer des données historiques de transaction au terminal et d'envoyer des interfaces de paiement pour recevoir en retour des données de validation de paiement.
Matériellement, ce dispositif SP comporte un circuit de traitement 52 comportant un processeur et coopérant avec un bloc mémoire BM comportant une mémoire de stockage et/ou de travail MEM.
Le processeur pilote des modules de traitement aptes à mettre en œuvre le procédé d'envoi de données de validation selon l'invention. Ainsi, ce dispositif comporte une mémoire comportant des données historiques de transaction entre l'utilisateur et le site de paiement. Cette mémoire peut être sous la forme d'une base de données 55 interne au serveur ou bien externe à celui-ci. Le module de traitement faisant alors appel à cette base de données par l'intermédiaire du module de communication 51.
Le dispositif ou serveur SP comporte un module 54 d'obtention d'au moins une de ces données, piloté par le circuit de traitement et apte à lire dans la base de données ces données historiques mémorisées en correspondance avec des identifiants d'utilisateur.
Le module de communication 51 est apte à envoyer au terminal TA, les données historiques obtenues et à recevoir un code de validation de la transaction de l'utilisateur du terminal, la réception du code de validation étant conditionnée à la vérification de validité des données historiques envoyées.
Le dispositif SP comporte un module 53 de validation du paiement après vérification du code de validation selon des données d'authentification de l'utilisateur qu'il possède en mémoire MEM ou dans la base de données 55.
Le bloc mémoire peut avantageusement comporter un programme informatique (prog2.) comportant des instructions de code pour la mise en œuvre des étapes du procédé d'envoi de données de validation d'un site de paiement vers un terminal, lorsque ces instructions sont exécutées par le processeur PROC du module de traitement 52 et notamment, lors d'une transaction de paiement entre l'utilisateur du terminal et le site de paiement, les étapes d'obtention de données historiques de transaction entre l'utilisateur et le site de paiement, d'envoi d'au moins une donnée historique obtenue au terminal, d'attente de réception d'un code de validation de la transaction de l'utilisateur du terminal avant de valider le paiement, la réception du code de validation étant conditionnée à la vérification de validité de la au moins une donnée historique envoyée.
Ce programme peut 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'initialisation, les instructions du programme d'ordinateur (prog.2) sont par exemple chargées dans une mémoire RAM (Random Access Memory en anglais) avant d'être exécutées par le processeur de l'unité de traitement 52. Le processeur de l'unité de traitement 52 met en œuvre les étapes du procédé d'envoi de données de validation tel que décrit selon les instructions du programme d'ordinateur.
Typiquement, la description de la figure 2 reprend les étapes d'un algorithme d'un tel programme informatique. Le programme informatique peut également être stocké sur un support mémoire lisible par un lecteur du dispositif ou téléchargeable dans l'espace mémoire de celui-ci.
La mémoire MEM enregistre de manière générale, toutes les données nécessaires à la mise en œuvre du procédé d'envoi tel que décrit.

Claims (15)

  1. REVENDICATIONS
    1. Procédé de contrôle de validité d'une interface de paiement à distance sur un terminal, caractérisé en ce que, lors d'une transaction de paiement entre un utilisateur et un site de paiement à distance, le procédé comporte les étapes suivantes :
    - réception (E21) d'au moins une donnée historique de transaction entre l'utilisateur et le site de paiement ;
    - envoi (E23) d'un code de validation de la transaction dans le cas où la au moins un donnée historique est vérifiée (E22) comme étant valide.
  2. 2. Procédé selon la revendication 1, dans lequel la au moins une donnée historique reçue est affichée sur une interface de paiement comprenant une demande de code de validation.
  3. 3. Procédé selon la revendication 2, dans lequel l'affichage de la au moins une donnée historique est associé à l'affichage d'une information de mise en garde de l'utilisateur en cas de non validité de la au moins une donnée historique.
  4. 4. Procédé selon la revendication 1, dans lequel la au moins une donnée historique est restituée vocalement à l'utilisateur via une interface vocale du terminal.
  5. 5. Procédé selon l'une des revendications 1 à 4, dans lequel la au moins une donnée historique comporte des données de date et de montant de la dernière transaction ou de plusieurs dernières transactions.
  6. 6. Procédé selon l'une des revendications 1 à 5, dans lequel une donnée de transaction est une adresse de livraison de l'utilisateur.
  7. 7. Procédé selon l'une des revendications 1 à 6, dans lequel la vérification que la au moins une donnée historique est valide, comprend une étape de comparaison de données de transactions mémorisées dans le terminal et d'affichage d'un message de validation de la vérification sur une interface de paiement.
  8. 8. Procédé selon l'une des revendications 2 à 6, dans lequel la vérification que la au moins une donnée historique est valide est effectuée par l'utilisateur par la visualisation des données historiques affichées ou par l'écoute des données historiques restituées, avant une étape d'interaction avec l'interface de paiement pour entrer des données de validation de la transaction.
  9. 9. Procédé d'envoi de données de validation d'un site de paiement vers un terminal, caractérisé en ce que, lors d'une transaction de paiement entre l'utilisateur du terminal et le site de paiement, le procédé comporte les étapes suivantes :
    - obtention (E28) de données historiques de transaction entre l'utilisateur et le site de paiement ;
    - envoi (E29) d'au moins une donnée historique obtenue au terminal ;
    - attente de réception (E30) d'un code de validation de la transaction de l'utilisateur du terminal avant de valider (E32) le paiement, la réception du code de validation étant conditionnée à la vérification de validité de la au moins une donnée historique envoyée.
  10. 10. Procédé selon la revendication 8, dans lequel la au moins une donnée historique est envoyée avec une interface de paiement comportant une demande de code de validation de la transaction.
  11. 11. Dispositif de contrôle de validité d'une interface de paiement à distance, caractérisé en ce qu'il comporte un circuit de traitement (42) comportant un processeur et étant apte à contrôler:
    - un module d'affichage (43) d'une interface de transaction de paiement lors d'une transaction de paiement entre un utilisateur et un site de paiement à distance ;
    - un module de communication (41) apte à-rece voir au moins une donnée historique de transaction entre l'utilisateur et le site de paiement et à envoyer un code de validation de la transaction via une interaction avec l'interface de paiement, dans le cas où la au moins un donnée historique est vérifiée comme étant valide.
  12. 12. Terminal de communication comportant un dispositif selon la revendication 11.
  13. 13. Serveur d'un site de paiement, caractérisé en ce qu'il comporte un circuit de traitement comportant un processeur et étant apte à contrôler lors d'une transaction de paiement entre un utilisateur et le site de paiement :
    - une mémoire (55) comportant des données historiques de transaction entre l'utilisateur et le site de paiement et un module d'obtention (54) d'au moins une de ces données ;
    - un module de communication (51) apte à envoyer au terminal la au moins une donnée historique obtenue et à recevoir un code de validation de la transaction de l'utilisateur du terminal, la réception du code de validation étant conditionnée à la vérification de validité de la au moins donnée historique envoyée;
    - un module de validation (53) du paiement après vérification du code de validation.
  14. 14. Programme informatique comportant des instructions de code pour la mise en œuvre des étapes du procédé de contrôle de validité d'une interface de paiement à distance selon l'une des revendications 1 à 8 et/ou du procédé d'envoi de données de validation d'un site de paiement selon l'une des revendications 9 à 10, lorsque ces instructions sont exécutées par un processeur.
  15. 15. Support de stockage, lisible par un processeur, sur lequel est enregistré un programme informatique comportant des instructions de code pour l'exécution des étapes du procédé de contrôle de validité d'une interface de paiement à distance selon l'une des revendications 1 à 8 et/ou du procédé d'envoi de données de validation d'un site de paiement selon l'une des revendications 9 à 10.
FR1755832A 2017-06-26 2017-06-26 Controle de validite d'une interface de paiement a distance Pending FR3067499A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
FR1755832A FR3067499A1 (fr) 2017-06-26 2017-06-26 Controle de validite d'une interface de paiement a distance
PCT/FR2018/000157 WO2019002703A1 (fr) 2017-06-26 2018-06-06 Contrôle de validité d'une interface de paiement à distance
EP18737653.8A EP3646267A1 (fr) 2017-06-26 2018-06-06 Contrôle de validité d'une interface de paiement à distance
US16/626,466 US20200118134A1 (en) 2017-06-26 2018-06-06 Checking of validity of a remote payment interface

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1755832A FR3067499A1 (fr) 2017-06-26 2017-06-26 Controle de validite d'une interface de paiement a distance
FR1755832 2017-06-26

Publications (1)

Publication Number Publication Date
FR3067499A1 true FR3067499A1 (fr) 2018-12-14

Family

ID=59811550

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1755832A Pending FR3067499A1 (fr) 2017-06-26 2017-06-26 Controle de validite d'une interface de paiement a distance

Country Status (4)

Country Link
US (1) US20200118134A1 (fr)
EP (1) EP3646267A1 (fr)
FR (1) FR3067499A1 (fr)
WO (1) WO2019002703A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020128203A1 (fr) * 2018-12-21 2020-06-25 Orange Procédé et système de sécurisation d'opérations, et poste utilisateur associé
CN114298702A (zh) * 2021-12-28 2022-04-08 蜂助手股份有限公司 支付通道可用性的预警方法、装置及计算机可读存储介质

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112418852A (zh) * 2019-08-23 2021-02-26 中兴通讯股份有限公司 安全支付方法、终端、服务器及支付系统
FR3135372A1 (fr) * 2022-05-03 2023-11-10 Orange Procédés et dispositifs permettant une interaction enrichie entre un véhicule connecté et un agent conversationnel.

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150052005A1 (en) * 2013-08-15 2015-02-19 Mastercard International Incorporated Internet site authentication with payments authorization data

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10853855B2 (en) * 2007-05-20 2020-12-01 Michael Sasha John Systems and methods for automatic and transparent client authentication and online transaction verification

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150052005A1 (en) * 2013-08-15 2015-02-19 Mastercard International Incorporated Internet site authentication with payments authorization data

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020128203A1 (fr) * 2018-12-21 2020-06-25 Orange Procédé et système de sécurisation d'opérations, et poste utilisateur associé
FR3090934A1 (fr) * 2018-12-21 2020-06-26 Orange Procédé et système de sécurisation d’opérations, et poste utilisateur associé
CN114298702A (zh) * 2021-12-28 2022-04-08 蜂助手股份有限公司 支付通道可用性的预警方法、装置及计算机可读存储介质

Also Published As

Publication number Publication date
WO2019002703A1 (fr) 2019-01-03
EP3646267A1 (fr) 2020-05-06
US20200118134A1 (en) 2020-04-16

Similar Documents

Publication Publication Date Title
EP3243176B1 (fr) Procédé de traitement d'une transaction à partir d'un terminal de communication
EP1330798B1 (fr) Procede de paiement par telematique securise
EP1153376B1 (fr) Procede de telepaiement et systeme pour la mise en oeuvre de ce procede
FR2820853A1 (fr) Procede et systeme de telepaiement
WO2019002703A1 (fr) Contrôle de validité d'une interface de paiement à distance
CN101331788A (zh) 无线因特网中业务服务器的认证和使用该认证的结算
WO2013021107A1 (fr) Procede, serveur et systeme d'authentification d'une personne
WO2001043092A1 (fr) Procede et systeme de gestion d'une transaction securisee a travers un reseau de communication
WO2015059389A1 (fr) Procede d'execution d'une transaction entre un premier terminal et un deuxieme terminal
EP3857413A1 (fr) Procede de traitement d'une transaction, dispositif, systeme et programme correspondant
EP3142054A1 (fr) Procédé de transmission de données, dispositifs et programmes d'ordinateur correspondants
EP2824625B1 (fr) Méthode de réalisation de transaction, terminal et programme d'ordinateur correspondant
WO2021116627A1 (fr) Procede, serveur et systeme d'authentification de transaction utilisant deux canaux de communication
FR2843664A1 (fr) Procede et systeme de securisation de transmission d'informations sur des reseaux de telecommunication
Rout Mobile Banking Security: Technological Security
FR2823882A1 (fr) Procede et systeme de validation de paiement
WO2001073706A1 (fr) Systeme de paiement permettant de ne pas divulguer d'information bancaire sur le reseau public et quasi-public
CA2946145C (fr) Procedes de traitement de donnees transactionnelles, dispositifs et programmes correspondants
WO2005088568A1 (fr) Procede et systeme de micropaiement
WO2021053300A1 (fr) Procede de transmission d'une information complementaire relative a une transaction financiere
FR3011111A1 (fr) Securisation d'une transmission de donnees d'identification
BE1016964A3 (fr) Methode et systeme de paiements electroniques entre porte-monnaies electroniques.
EP3223219A1 (fr) Procédé de transfert de transaction, procédé de transaction et terminal mettant en oeuvre au moins l'un d'eux
FR2912579A1 (fr) Procede de transfert securise via un reseau de communication d'un flux monetaire, systeme de transfert et produit programme correspondants
FR2876530A1 (fr) Procede d'intermediation dans une transaction entre un terminal client et un serveur fournisseur de reponses, et serveur associe

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20181214

RX Complete rejection

Effective date: 20200220