EP3646267A1 - Contrôle de validité d'une interface de paiement à distance - Google Patents
Contrôle de validité d'une interface de paiement à distanceInfo
- Publication number
- EP3646267A1 EP3646267A1 EP18737653.8A EP18737653A EP3646267A1 EP 3646267 A1 EP3646267 A1 EP 3646267A1 EP 18737653 A EP18737653 A EP 18737653A EP 3646267 A1 EP3646267 A1 EP 3646267A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- payment
- user
- transaction
- data
- terminal
- 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.)
- Ceased
Links
- 238000000034 method Methods 0.000 claims abstract description 52
- 238000010200 validation analysis Methods 0.000 claims description 75
- 238000004891 communication Methods 0.000 claims description 27
- 238000004590 computer program Methods 0.000 claims description 18
- 238000012545 processing Methods 0.000 claims description 15
- 238000012795 verification Methods 0.000 claims description 12
- 230000006870 function Effects 0.000 claims description 8
- 230000003993 interaction Effects 0.000 claims description 5
- 238000013524 data verification Methods 0.000 claims description 2
- 230000009471 action Effects 0.000 description 6
- 230000001413 cellular effect Effects 0.000 description 3
- 230000001143 conditioned effect Effects 0.000 description 2
- 238000010295 mobile communication Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000000007 visual effect Effects 0.000 description 2
- 230000005055 memory storage Effects 0.000 description 1
- 238000004377 microelectronic Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000012800 visualization Methods 0.000 description 1
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
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.
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
Description
Claims
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 |
PCT/FR2018/000157 WO2019002703A1 (fr) | 2017-06-26 | 2018-06-06 | Contrôle de validité d'une interface de paiement à distance |
Publications (1)
Publication Number | Publication Date |
---|---|
EP3646267A1 true EP3646267A1 (fr) | 2020-05-06 |
Family
ID=59811550
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP18737653.8A Ceased EP3646267A1 (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) |
Families Citing this family (4)
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é |
CN112418852A (zh) * | 2019-08-23 | 2021-02-26 | 中兴通讯股份有限公司 | 安全支付方法、终端、服务器及支付系统 |
CN114298702A (zh) * | 2021-12-28 | 2022-04-08 | 蜂助手股份有限公司 | 支付通道可用性的预警方法、装置及计算机可读存储介质 |
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. |
Family Cites Families (2)
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 |
US20150052005A1 (en) * | 2013-08-15 | 2015-02-19 | Mastercard International Incorporated | Internet site authentication with payments authorization data |
-
2017
- 2017-06-26 FR FR1755832A patent/FR3067499A1/fr active Pending
-
2018
- 2018-06-06 WO PCT/FR2018/000157 patent/WO2019002703A1/fr unknown
- 2018-06-06 EP EP18737653.8A patent/EP3646267A1/fr not_active Ceased
- 2018-06-06 US US16/626,466 patent/US20200118134A1/en not_active Abandoned
Also Published As
Publication number | Publication date |
---|---|
WO2019002703A1 (fr) | 2019-01-03 |
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 | |
WO2019002703A1 (fr) | Contrôle de validité d'une interface de paiement à distance | |
CN101454794A (zh) | 移动的个人之间支付系统 | |
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 | |
FR3012645A1 (fr) | Procede d'execution d'une transaction entre un premier terminal et un deuxieme terminal | |
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 | |
WO2005088568A1 (fr) | Procede et systeme de micropaiement | |
WO2021053300A1 (fr) | Procede de transmission d'une information complementaire relative a une transaction financiere | |
BE1016964A3 (fr) | Methode et systeme de paiements electroniques entre porte-monnaies electroniques. | |
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 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: UNKNOWN |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE |
|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE |
|
17P | Request for examination filed |
Effective date: 20200103 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
AX | Request for extension of the european patent |
Extension state: BA ME |
|
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: ORANGE |
|
DAV | Request for validation of the european patent (deleted) | ||
DAX | Request for extension of the european patent (deleted) | ||
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: EXAMINATION IS IN PROGRESS |
|
17Q | First examination report despatched |
Effective date: 20201015 |
|
RAP3 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: ORANGE |
|
REG | Reference to a national code |
Ref country code: DE Ref legal event code: R003 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED |
|
18R | Application refused |
Effective date: 20220723 |