WO2019002703A1 - Contrôle de validité d'une interface de paiement à distance - Google Patents

Contrôle de validité d'une interface de paiement à distance Download PDF

Info

Publication number
WO2019002703A1
WO2019002703A1 PCT/FR2018/000157 FR2018000157W WO2019002703A1 WO 2019002703 A1 WO2019002703 A1 WO 2019002703A1 FR 2018000157 W FR2018000157 W FR 2018000157W WO 2019002703 A1 WO2019002703 A1 WO 2019002703A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
user
transaction
data
terminal
Prior art date
Application number
PCT/FR2018/000157
Other languages
English (en)
Inventor
Eric Beaufils
Emmanuel Le Huerou
François Toutain
Original Assignee
Orange
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 filed Critical Orange
Priority to US16/626,466 priority Critical patent/US20200118134A1/en
Priority to EP18737653.8A priority patent/EP3646267A1/fr
Publication of WO2019002703A1 publication Critical patent/WO2019002703A1/fr

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 OR SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING; 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

Definitions

  • the present invention relates to the field of online payment and online payment interfaces during a transaction between a user and a secure payment server.
  • the merchant site When requesting a purchase of a product or service between a merchant site and a user of a terminal, the merchant site uses a payment site to validate the transaction and recover the payment.
  • the payment site asks the user to authenticate before validating the payment- This is, for the payment site, to verify that the user is indeed the owner of the bank account or account. payment,
  • the user is redirected to a payment site interface and II must prove his identity by entering the password or code.
  • the payment site is able to ensure the authentication of the user of the transaction, it is not the same for the user who does not have an effective way to ensure the validity the payment interface that is offered to him.
  • one way to verify that the payment interface is valid when this interface is open on a browser, is to verify that the protocol used is a secure protocol "https" certifying the validity of the domain name on which the payment interface is hosted.
  • This information of the domain name is displayed on the interface and is associated with an illustration in the form of a closed padlock on the navigation interface, However, there are different possibilities of misleading the user of such an interface. This padlock illustration is not very visible and the user does not necessarily notice that it is not present.
  • the forger 5 can predict on his forged interface, the illustration of the same lock and thus mislead the user who does not necessarily recognize a domain name valid from another falsified, especially if they are voluntarily similar.
  • the present invention improves the situation.
  • the method is such that, during a payment transaction between a user and a remote payment site, it comprises the following steps:
  • the transaction history data of the user with the payment site allow the user or the user's terminal to ensure that the payment site is indeed a payment site that the user has already used for past transactions. This payment site is therefore not fraudulent and the user can then insert his payment validation code with confidence.
  • the at least one historical data item received is displayed on a payment interface comprising a request for a validation code
  • the user can verify that the historical information is valid.
  • the display on the same interface of the code request and historical data ensures the user that it is the same server that sends these two information.
  • the displayed historical data correspond to the payment site that requests the validation code.
  • the display of the at least one historical data item is associated with the display of warning information of the user in case of no validity of the at least one historical data.
  • the at least one historical datum is rendered vocally to the user via a voice interface of the terminal
  • the at least one historical data item includes date and amount data of the last transaction or of several last transactions or a delivery address of the user.
  • This data makes it easy to identify past transactions or the link that the payment site has already had with the user.
  • the method comprises a step of comparing transaction data stored in the terminal and displaying a validation message of a valid historical data verification on a payment interface.
  • This step is then performed automatically by the terminal which contains in memory the transaction data passed with one or more payment sites.
  • the terminal receiving the historical data can then compare according to the payment site, if the information received are those stored and can then display a message to the user confirming the validity of the information received, so that it can enter the code payment validation with confidence.
  • a verification step that the at least one historical data is valid is performed by the user by viewing the displayed historical data or by listening to the historical data restored, before a step of interaction with the payment interface to enter transaction validation data.
  • the user must then remember the last transactions he has made with the payment site. If it does not recognize the historical data that is displayed then it does not enter the payment validation code and the transaction fails.
  • the invention also relates to a method of sending validation data from a payment site to a terminal.
  • the method is such that, during a payment transaction between the terminal user and the payment site, it comprises the following steps:
  • the reception of the validation code being a function of the at least one historical data sent.
  • the payment server thus finds the historical data of transactions already made between him and the user who wishes to validate the payment. By sending this information to the user's terminal, it allows the user to verify that this site is not a fraudulent site, the transaction can be finalized by receiving the validation code of the user .
  • the at least one historical datum is sent with a payment interface comprising a transaction validation code request
  • the invention aims at a device for checking the validity of a remote payment interface.
  • This device comprises a processing circuit comprising a processor and being able to control:
  • a communication module able to receive at least one transaction history data between the user and the payment site and to send a validation code of the transaction via an interaction with the payment interface, depending on the at least one a historical datum.
  • the invention also relates to a communication terminal comprising a device as described.
  • the device and the terminal thus described have the same advantages as the described control method they implement.
  • the invention relates to a server of a payment site.
  • This server comprises a processing circuit comprising a processor and being able to control during a payment transaction between a user and the payment site:
  • a memory comprising transaction history data between the user and the payment site and a module for obtaining at least one of these data
  • a communication module able to send the terminal the at least one historical data obtained and to receive a validation code from the transaction of the user of the terminal, the receipt of the validation code being a function of the at least one sent historical data;
  • the server thus described has the same advantages as the method of sending validation data described that implements.
  • the invention relates to a computer program comprising code instructions for implementing the steps of the validity control method of a remote payment interface as described above, as well as a computer program comprising code instructions for the remote payment interface as described above. implementing the steps of the method of sending validation data of a payment site as described, when these instructions are executed by a processor.
  • the invention relates to a storage medium, readable by a processor, storing a computer program implementing a validity control method of a remote payment interface as described above, and a computer program setting implementing a method of sending validation data of a payment site as described above.
  • the storage medium may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, a CD ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a hard disk.
  • the storage medium may be a transmissive medium such as an electrical or optical signal, which may be routed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can be downloaded in particular on an Internet type network.
  • the storage medium may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • FIG. 1 illustrates a system including a terminal and a payment server implementing the invention in one embodiment
  • FIG. 2 illustrates in flowchart form the main steps of an embodiment of a method for verifying the validity of a payment interface implemented by the terminal and of a method for sending data from validation implemented by a payment server;
  • FIGS. 3a, 3b and 3c illustrate payment interfaces displayed on a terminal in particular embodiments of the invention
  • FIG. 4 diagrammatically illustrates a hardware representation of a terminal comprising a validity control device and implementing a validity checking method according to one embodiment of the invention
  • FIG. 5 illustrates a hardware representation of a payment server implementing a method for sending validation data according to one embodiment of the invention.
  • the terminal TA here represented by a mobile terminal, comprises a communication interface for communicating to the network R where two servers are represented, a merchant server SM hosting a merchant site offering the purchase of products or services and a payment server able to receive payment orders for the products or services requested and to validate these payments with the banks concerned or more generally with a payment account, the payment account may be hosted by a third party payment not necessarily offering banking service.
  • the merchant server and the payment server can be confused.
  • the network R is a communication network, for example of IMS type, which allows the establishment of communications between terminals and servers as shown here.
  • the terminal TA can communicate to the SM or SP servers via a conversational commerce service based on an enriched instant messaging application, installed on the terminal and which allows to exchange with a robot adapted to the merchant site, for example, to control goods or services. Users of such enriched instant messaging applications no longer need to download applications dedicated to each merchant site or access their website to order.
  • Action buttons or hypertext links can also be provided on the conversational trading interface to trigger a purchase action or consultation of web pages.
  • the invention is not limited to the framework of the MS networks.
  • the communication network R may be a GSM (Global System for Mobile Communication) telecommunication network enabling the establishment of voice communications and the exchange of text messages by means of SMS (short message service) for example.
  • GSM Global System for Mobile Communication
  • the network R is for example also the internet network to which the terminal TA can connect to exchange data and access, among other things, the web pages of the merchant site and carry out its orders.
  • the network R may also correspond to several separate and interconnected networks from which the SM and SP servers are accessible.
  • the terminal TA may establish voice communications via a fixed switched network or a cellular network and textual communications or data exchange via a WiFi access network, 2G, 3G or 4G,
  • the TA terminal is here a mobile phone type "smartphone" with communications means adapted to connect to one or more communication networks, such as wireless networks or cellular networks, as well as a memory and a processor adapted to execute computer program instructions.
  • the invention described below may, however, be implemented on other terminals, such as on a tablet, a connected object, a vehicle dashboard or a computer person !.
  • the terminal TA is for example adapted to communicate according to at least one instant messaging protocol with other terminals or devices.
  • the terminal TA can send and receive messages of the SMS (Short Message Service) type via a cellular network, or else implement the CS (Rien Communication Suite) standard, the SIP SIMPLE protocol, Jabber or any other suitable protocol for sending and receiving messages.
  • the terminal TA can exchange instant messages with the server SM through the network R.
  • FIG. 2 represents the steps (E20 to E23) of a method for checking the validity of a payment interface implemented in the terminal TA, in one embodiment, as well as the steps (E27 to E33) of FIG. a method of sending validation data of a payment site implemented, for example, in a payment server SP.
  • FIG. 2 also represents the steps implemented on a merchant server SM offering products or services to the user of the terminal TA.
  • This merchant server can also be a conversational agent (or robot) to offer the user goods or services of different merchants via an instant messenger.
  • the merchant server and the payment server can be one and the same server.
  • step E20 the user of the terminal TA, after consultation of a website of the merchant site or after exchange of an instant messaging conversation proposing the purchase of service or product, decides to validate an order by validating the aéation of a basket for example. It performs an order in E20, which it sends to the server S for it to validate and triggers the sending of a payment order.
  • the merchant site server, SM receives this command in E24 and transmits the payment order to a payment server SP for it to interact with the user of the terminal TA to validate the payment.
  • the payment server receives this payment order in E27.
  • these exchange steps for example for a conversational business application installed on the terminal TA, during the validation of a command by the user of the terminal, it can receive, from the SM server's conversational agent, a link or action button that allows him to pay and puts him directly in touch with the payment server.
  • This action button when the terminal user activates it, implements an application for exchanging the identifiers at the hands of the user of the terminal TA and the merchant site as well as the information on the requested transaction for the current order.
  • the payment server, SP receiving this payment order in E27, consults an internal or external database in which are stored information of the last transactions made in correspondence with an identifier of the issuer of the order.
  • step E28 the payment server therefore consults in its database and obtains the transaction data passed corresponding to the identifier of the user who issued the order for this payment order.
  • This historical data is for example, the date and the amount of the last one or the last 2 or 3 payments that the user has made on this payment site. He can also see the name of the corresponding commercial site.
  • Another data may be the delivery address used for the last purchases and transactions made by this user.
  • This historical data is multimedia data, it can be in the form of text, image or sound and always relative to the user.
  • the transaction history data thus described exist only if the user has already made a payment via this payment site.
  • personal data of the user can then be sent as historical data, This personal data has for example been recorded on the server when the user has created his account with the payment server. It can be an answer to a personal question or a personal information about his identity.
  • the terminal TA receives this historical data of transactions made with the payment site.
  • This historical data is, in one embodiment, displayed on the payment interface and on the terminal screen.
  • they are vocally delivered to the user via a voice interface of the terminal.
  • the user can verify that the historical information is valid.
  • the display on the same interface of the code request and historical data ensures the user that it is the same server that sends these two information.
  • the displayed historical data correspond to the payment site that requests the validation code.
  • the display of the historical data is associated with the display of a warning information of the user in case of invalidity of these historical data
  • a step H22 of checking the validity of this data is performed.
  • This step is, in a possible embodiment, carried out by the user himself, by the visualization on the payment interface of the historical data of transaaions displayed or by listening to the historical data restored.
  • the user then ensures that the payment site is a payment site that the user has already used for past transactions. This payment site is not fraudulent and the user can then insert his payment validation code with confidence by interacting with the payment interface to enter his transaction validation data.
  • the user can request the payment server other historical information in response to this first shipment, in case it is not certain to be able to validate these first data.
  • the interface can thus provide an action button triggering the request of another data to the server.
  • the payment server thus retrieves at least one other historical data that concerns the user and sends a second sending of these data to the user.
  • a limited number of successive requests can be expected. After this number, the transaction is automatically canceled.
  • the verification step E22 comprises a step of comparing transaction data stored in the terminal and displaying a verification validation message on the terminal. payment interface.
  • steps are then performed by the terminal itself which has stored in memory the latest transaction data and can compare them with the historical data received.
  • the terminal implements this step via for example its internal operating system or in a particular embodiment and in the case of the implementation of conversational trade, via the instant messaging software platform.
  • This comparison is made before the posting of the validation code request on the payment interface.
  • This display is then accompanied by a message confirming that the terminal has verified the historical data it has received. The user can then confidently enter his validation code.
  • the payment server When the payment server receives the validation code in E30, it verifies in E31 that ⁇ validation code corresponds to the authentication data of the user for this command and validates the transaction when this verification is positive. Otherwise, the transaction fails.
  • FIGS. 3a to 3c An example of a payment interface received on the terminal TA is illustrated in FIGS. 3a to 3c.
  • FIG. 3a shows a payment interface with an "Orange Cash" payment server, displayed on the terminal of a user who has placed an order with a merchant 3 whose address is displayed. The order number is also displayed along with the associated amount. The account of the user who will make the payment is also displayed. To make the payment, the user activates the "pay” button on this interface. If it cancels this command, it activates the "cancel" button.
  • the action on the "pay” button enables the triggering of the validity check method of the payment interface on the terminal as well as the implementation of the corresponding method of sending validation data to the payment server.
  • the payment server consults its database to find the last transaction data that the user had with this payment site. This data is sent to the terminal which displays them according to an example illustrated in FIG. 3b.
  • This data may be accompanied by a first explanatory message (MESS 1) of the type "Check that you can validate the information below before validating the payment”.
  • a warning message may also be displayed (MESS 2) of the type "If this information is not yours or does not correspond to you, DO NOT ENTER YOUR PIN CODE".
  • the entry of the PIN code in question can then be done in the squares provided for this purpose on the interface.
  • the payment interface may be a little different as illustrated in Figure 3c.
  • a message MESS 3 can inform that the terminal has done its verification.
  • This message can be of the type "The historical data of the last transactions received and displayed below have been validated"
  • a message "MESS 4" can confirm that the user can enter his PIN with confidence, This message can be of the type "The payment site is valid, you can enter your PIN with confidence”.
  • the historical data may not be displayed in this embodiment since it is the terminal that performs the verification with the data that! has in memory.
  • the message MESS 3 does not include the words "and displayed below".
  • the visual interfaces thus represented can be transformed into voice interfaces.
  • the historical data received are thus vocalized along with the messages accompanying them.
  • the payment interface may be a voice interface in which the user is asked to enter his payment validation code vocally after verifying the historical data.
  • these interfaces may consist of a voice part, for example the historical data received and rendered vocally and a visual part, for example the payment interface, the entry of the validation code by the user. The user is then touched by a keypad or not.
  • FIG. 4 now illustrates a hardware representation of a device for checking the validity of a remote payment interface TA according to one embodiment of the invention.
  • This device can be integrated with a communication terminal, for example a terminal of mobile communication, such as "smartphone", computer, tablet, connected object or other equipment,
  • This device implements the method of checking the validity of a payment interface described with reference to FIG. 2 by the main steps E20 to E23.
  • this device TA comprises a processing circuit 42 comprising a processor and cooperating with a memory block BM having a storage memory and or working MEM.
  • the processor controls processing modules able to implement the validity control method described with reference to FIG. 2.
  • the term module can correspond to a software component as well as a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or subprograms or more generally any element of a program capable of implementing a function or a set of functions as described for the modules concerned.
  • a hardware component corresponds to any element of a hardware set (or hardware) able to implement a function or a set of functions for the module concerned (integrated circuit, smart card, memory card, etc. .)
  • the memory block may advantageously comprise a computer program (progl.) Comprising code instructions for implementing the steps of the validity control method of a remote payment interface within the meaning of the invention, when these instructions are performed by the processor PROC and in particular, during a payment transaction between a user and a remote payment site, the steps of receiving at least one transaction history data between the user and the payment site and of sending a validation code of the transaction according to the at least one historical data.
  • a computer program program
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other form desirable shape.
  • the instructions of the computer program are for example loaded into a RAM (Random Access Memory in English) before being executed by the processor of the processing unit 42.
  • the processor of the processing unit 42 implements the steps of the control method as described according to the instructions of the computer program.
  • FIG. 2 repeats the steps of an algorithm of such a computer program.
  • the computer program can also be stored on a memory medium readable by a reader of the device or downloadable in the memory space thereof.
  • the memory MEM generally records all the data necessary for the implementation of the control method and in particular, in one embodiment of the control method, data concerning the last transactions made in correspondence with the payment sites concerned.
  • the device also has a screen 43 capable of displaying the control interfaces and the payment transaction interfaces. The screen is thus able to display the transaction history data received from a payment server and to simultaneously display an input request. payment validation code.
  • the device also comprises a user interface 44 (for example a tactile interface on the screen or a physical keyboard type interface) allowing the user to interact during an order or payment, for example by entering a code payment validation in case the transaction history data has been verified as valid.
  • a user interface 44 for example a tactile interface on the screen or a physical keyboard type interface
  • the user interface 44 may also, in one embodiment, be a voice interface which translates the received messages, and in particular the historical data received, into voice messages via high-wager type speech reproduction means not represented here,
  • this voice interface can receive voice messages from the user via sound capturing means such as microphones not shown here.
  • the device TA also comprises a communication module capable of receiving one or more transaction history data between the user and the payment site and sending a validation code of the transaction via an interaction with the user interface 44 and the interface of the transaction. payment posted, in case the transaction history data has been verified as valid.
  • This communication module 41 is for example a COM network interface (for example a WiB, 3G, 4G or ethernet interface), enabling the device to connect to a telecommunications network R and to exchange data with other devices or servers of the merchant server and payment server type, via the telecommunications network.
  • This communication module makes it possible in particular to exchange messages with a conversational agent in the case of a conversational trade implementation.
  • FIG. 5 now illustrates a hardware representation of an SP device for sending validation data of a payment site according to one embodiment of the invention.
  • This device can be integrated with a payment server in a communication network.
  • This device implements the method of sending validation data of a payment site described with reference to FIG. 2 by the main steps E27 to E33.
  • the communication module 51 has a communication module 51 making it possible to communicate with other equipment of the communication network, for example with the terminal TA.
  • the communication module 51 may be for example a WiFi, 3G or 4G network interface or an Ethernet interface. allows the device to transmit messages to the TA terminal OR to another server on the network, for example a merchant server SM. I! allows sending transaction history data to the terminal and sending payment interfaces to receive payment validation data back.
  • this device SP comprises a processing circuit 52 comprising a processor and cooperating with a memory block BM comprising a memory storage and / or working MEM.
  • the processor controls processing modules adapted to implement the method of sending validation data according to the invention.
  • this device comprises a memory comprising historical transaction data between the user and the payment site.
  • This memory may be in the form of a database 55 internal to the server or external to it.
  • the processing module then uses this database via the communication module 51.
  • the device or server SP comprises a module 54 for obtaining at least one of these data, driven by the processing circuit and able to read from the database these historical data stored in correspondence with user identifiers,
  • the communication module 51 is able to send to the terminal TA, the historical data obtained and to receive a validation code of the transaction of the user of the terminal, the receipt of the validation code being conditioned to the verification of validity of the historical data. sent.
  • the device SP comprises a module 53 for validating the payment after verification of the validation code according to the authentication data of the user that it has in the memory MEM or in the database 55.
  • the memory block can advantageously comprise a computer program (prog2.) Comprising code instructions for implementing the steps of the method of sending validation data from a payment site to a terminal, when these instructions are executed by the processor PROC of the processing module 52 and in particular, during a payment transaction between the user of the terminal and the payment site, the steps of obtaining historical transaction data between the user and the payment site, sending at least one historical data obtained at the terminal, waiting to receive a validation code of the transaction of the user of the terminal before validating the payment, the receiving the validation code being conditioned on the verification of validity of the at least one historical data sent.
  • program program
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other form desirable shape.
  • the instructions of the computer program are for example loaded into a RAM (Random Access Memory in English) before being executed by the processor of the processing unit 52.
  • the processor of the processing unit 52 implements the steps of the method of sending validation data as described according to the instructions of the computer program.
  • FIG. 2 repeats the steps of an algorithm of such a computer program.
  • the computer program can also be stored on a memory medium readable by a reader of the device or downloadable in the memory space thereof.
  • the memory MEM generally records all the data necessary for the implementation of the sending method as described.

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 en fonction de la au moins une donnée historique. 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

Contrôle de validité d'une interface de paiement à distance
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 PïN (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 II 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 linterface 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 linterface 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 5 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 i o 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 15 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.
0 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 5 l'utilisateur et le site de paiement ;
- envoi d'un code de validation de la transaction en fonction de la au moins une donnée historique.
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 0 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 i'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 5 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, le procédé comprend une étape de comparaison de données de transactions mémorisées dans le terminal et d'affichage d'un message de validation d'une vérification de donnée historique valide 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, une étape de 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 terminai avant de valider le paiement, la réception du code de validation étant fonction 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, en fonction de la au moins une donnée historique.
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 fonction 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 l 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 ta 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 oeuvre 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 oeuvre 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 transmissibie 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 aite 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ématlquement 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 t sur laquelle on a représenté un terminai 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 ïMS. 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 personne!. 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 CS (Rien 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 aéation d'un panier par exemple. II effectue en E20 une commande, qu'il transmet au serveur S 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 Tordre 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 fols de l'utilisateur du terminal TA et du site marchand ainsi que les infonmations 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 H22 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 lui- même, par la visualisation sur l'interface de paiement des données historiques de transaaions 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 œuvre 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 !e 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 œ 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 3 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 terminai 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 Mi pour un montant de 10,87€ et la deuxième ayant été effectuée le 03.06.2017 chez le marchand 2 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 qui! 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 termina! 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, I 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'effectua nt 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 oeuvre 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 sous- programmes d'ordinateur ou de manière plus générale à tout élément d'un programme apte à mettre en œuvre 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 œuvre 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 œuvre 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 en fonction de la au moins une donnée historique.
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 dinteragir 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-parieurs 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 linterface 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 WiB, 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.
ïl 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 WiFi, 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. I! 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 terminai 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

REVENDICATIONS
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 en fonction de la au moins une donnée historique.
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.
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.
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.
Procédé selon l'une des revendications l*à 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.
Procédé selon l'une des revendications 1 à 5, dans lequel une donnée de transaction est une adresse de livraison de l'utilisateur.
Procédé selon l'une des revendications 1 à 6, comprenant une étape de comparaison de données de transactions mémorisées dans le terminal et d'affichage d'un message de vaiidatJon d'une vérification de donnée historique valide sur une interface de paiement.
8. Procédé selon l'une des revendications 2 à 6, dans lequel une étape de 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. . 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 ;
- envol (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 fonction de la au moins une donnée historique envoyée.
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, 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 à 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, en fonction de la au moins une donnée historique.
12. Terminal de communication comportant un dispositif selon la revendication 11.
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 en fonction de la au moins une donnée historique envoyée;
- un module de validation (53) du paiement après vérification du code de validation.
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 à 7 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. 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 à 7 et/ou du procédé d'envoi de données de validation d'un site de paiement selon l'une des revendications 9 à 10,
PCT/FR2018/000157 2017-06-26 2018-06-06 Contrôle de validité d'une interface de paiement à distance WO2019002703A1 (fr)

Priority Applications (2)

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

Applications Claiming Priority (2)

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

Publications (1)

Publication Number Publication Date
WO2019002703A1 true WO2019002703A1 (fr) 2019-01-03

Family

ID=59811550

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2018/000157 WO2019002703A1 (fr) 2017-06-26 2018-06-06 Contrôle de validité d'une interface de paiement à distance

Country Status (4)

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

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4274186A1 (fr) * 2022-05-03 2023-11-08 Orange Procedes et dispositifs permettant une interaction enrichie entre un vehicule connecte et un agent conversationnel

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3090934A1 (fr) * 2018-12-21 2020-06-26 Orange Procédé et système de sécurisation d’opérations, et poste utilisateur associé

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080288405A1 (en) * 2007-05-20 2008-11-20 Michael Sasha John Systems and Methods for Automatic and Transparent Client Authentication and Online Transaction Verification

Family Cites Families (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

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080288405A1 (en) * 2007-05-20 2008-11-20 Michael Sasha John Systems and Methods for Automatic and Transparent Client Authentication and Online Transaction Verification

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4274186A1 (fr) * 2022-05-03 2023-11-08 Orange Procedes et dispositifs permettant une interaction enrichie entre un vehicule connecte et un agent conversationnel
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.

Also Published As

Publication number Publication date
EP3646267A1 (fr) 2020-05-06
FR3067499A1 (fr) 2018-12-14
US20200118134A1 (en) 2020-04-16

Similar Documents

Publication Publication Date Title
CN101331788B (zh) 无线因特网中业务服务器的认证和使用该认证的结算
EP1330798B1 (fr) Procede de paiement par telematique securise
US20090307778A1 (en) Mobile User Identify And Risk/Fraud Model Service
US8112314B2 (en) Escrow payment to faciliate on-line transactions
US20080288405A1 (en) Systems and Methods for Automatic and Transparent Client Authentication and Online Transaction Verification
US20100299212A1 (en) System and method for a commerce window application for computing devices
US11282072B2 (en) Automatic data pull requests using a secure communication link between online resources
FR2820853A1 (fr) Procede et systeme de telepaiement
CA2552257A1 (fr) Dispositif transactionnel a pre-traitement anticipe
WO2014140646A1 (fr) Système de commande et commande de service auxiliaire par messagerie textuelle
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
EP3646267A1 (fr) Contrôle de validité d'une interface de paiement à distance
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
WO2001073706A1 (fr) Systeme de paiement permettant de ne pas divulguer d'information bancaire sur le reseau public et quasi-public
FR2823882A1 (fr) Procede et systeme de validation de paiement
WO2019203982A2 (fr) Serveur et procédé d'envoi d'un reçu de transaction au moyen d'une notification de transfert
GB2523101A (en) Method and system for executing online transfer of assets
WO2005088568A1 (fr) Procede et systeme de micropaiement
WO2021053300A1 (fr) Procede de transmission d'une information complementaire relative a une transaction financiere
FR2831361A1 (fr) Jeton informatique
FR2912579A1 (fr) Procede de transfert securise via un reseau de communication d'un flux monetaire, systeme de transfert et produit programme correspondants
WO2013054058A1 (fr) Procede de realisation d'une transaction electronique

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18737653

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2018737653

Country of ref document: EP

Effective date: 20200127