EP3050034A1 - Méthode de traitement de données transactionnelles, terminal, serveur et programmes d'ordinateur correspondants - Google Patents

Méthode de traitement de données transactionnelles, terminal, serveur et programmes d'ordinateur correspondants

Info

Publication number
EP3050034A1
EP3050034A1 EP14777571.2A EP14777571A EP3050034A1 EP 3050034 A1 EP3050034 A1 EP 3050034A1 EP 14777571 A EP14777571 A EP 14777571A EP 3050034 A1 EP3050034 A1 EP 3050034A1
Authority
EP
European Patent Office
Prior art keywords
data
payment
application
payment terminal
consolidated
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
Application number
EP14777571.2A
Other languages
German (de)
English (en)
Inventor
Vincent DUCROHET
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Worldline MS France
Original Assignee
Ingenico Group SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ingenico Group SA filed Critical Ingenico Group SA
Publication of EP3050034A1 publication Critical patent/EP3050034A1/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/14—Payment architectures specially adapted for billing systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
    • G06K19/06—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code
    • G06K19/06009—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code with optically detectable marking
    • G06K19/06037—Record carriers for use with machines and with at least a part designed to carry digital markings characterised by the kind of the digital marking, e.g. shape, nature, code with optically detectable marking multi-dimensional coding
    • 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/20—Point-of-sale [POS] network systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3276—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being read by the M-device
    • 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
    • G06Q30/00—Commerce
    • G06Q30/04—Billing or invoicing
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0873—Details of the card reader
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0873—Details of the card reader
    • G07F7/088—Details of the card reader the card reader being part of the point of sale [POS] terminal or electronic cash register [ECR] itself
    • G07F7/0886—Details of the card reader the card reader being part of the point of sale [POS] terminal or electronic cash register [ECR] itself the card reader being portable for interacting with a POS or ECR in realizing a payment transaction

Definitions

  • the invention relates to the field of payment devices. More particularly, the invention relates to a payment device that has cash collection capabilities.
  • Payment terminals are now mainly used in shops to make payment purchases. Merchants favor these payment terminals because they offer a greater degree of transaction security than other means of payment (such as checks) and they make it possible to avoid the inconveniences associated with the possession of too much money. cash.
  • the payment terminal has become the preferred accessory of the merchant.
  • the payment terminal is not yet entirely adapted to the merchant's need due to a lack of business functionality.
  • merchants are calling for an integrated payment solution with the payment terminal.
  • payment solution one understands on the one hand an integration and a communication between the payment terminal and an intelligent cash register and on the other hand a respect of standards in force relating to the payment (such norms are generally built for a given country).
  • a terminal payment / cash register integration depends on the collection system (eg the cash register), the payment terminal and is generally only valid in one country.
  • the collection system eg the cash register
  • the proposed technique does not have these disadvantages of the prior art. More particularly, the proposed technique relates to a method of processing transactional data, via a payment terminal.
  • the proposed method differs in that it includes:
  • the proposed technique makes it possible to obtain data relating to the invoice without having to modify the operation of the cash register system (which may be a cash register). Indeed, by making a capture from an existing support (such as a receipt or a printed invoice, but also a screen of the collection system), it is not necessary to provide a specific development on the side of the collection system.
  • said step of capturing said consolidated data comprises:
  • said step of ca pture of said consolidated data further comprises, after said step of decoding said two-dimensional code, a step of decompressing the data of said two-dimensional code.
  • the data is compressed on the two-dimensional code, it is possible to transmit, on the code, more data than that which is normally possible to be transmitted by the user. intermediate of this type of code.
  • said step of capturing said consolidated data further comprises, after said step of decoding said two-dimensional code, a step of decrypting the data of said two-dimensional code.
  • the consolidated data can not be decrypted by any barcode capture application. Nor is it possible for a dishonest customer to defraud by modifying the content of the bar code.
  • said method further comprises, after the transmission, to said payment application of said payment terminal, said at least one data representative of a sum to pay:
  • the proposed technique may also take the form of a payment terminal comprising transactional data processing means.
  • transactional data processing means comprise:
  • transaction data means for transmitting, to a payment application of said payment terminal, at least one piece of data representative of a sum to be paid as a function of at least one element of said digital invoice, called transaction data.
  • the various steps of the methods according to the invention are implemented by one or more software or computer programs, comprising software instructions intended to be executed by a data processor of a relay module according to the invention. invention and being designed to control the execution of the various process steps.
  • the invention is also directed to a program that can be executed by a computer or a data processor, which program includes instructions for controlling the execution of the steps of a method as mentioned above.
  • 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 invention also relates to a data carrier readable by a data processor, and comprising instructions of a program as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a floppy disk or a disk. hard.
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed 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 information carrier 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.
  • the invention is implemented by means of software and / or hardware components.
  • module may correspond in this document as well to a software component, a hardware component or a set of hardware and software components.
  • a software component corresponds to one or more computer programs, one or more subroutines of a program, or more generally to any element of a program or software capable of implementing a function or a program. set of functions, as described below for the module concerned.
  • Such a software component is executed by a data processor of a physical entity (terminal, server, gateway, router, etc.) and is capable of accessing the hardware resources of this physical entity (memories, recording media, bus communication cards, input / output electronic cards, user interfaces, etc.).
  • a hardware component corresponds to any element of a hardware set (or hardware) able to implement a function or a set of functions, as described below for the module concerned. he may be a hardware component that is programmable or has an integrated processor for running software, for example an integrated circuit, a smart card, a memory card, an electronic card for executing a firmware ( firmware), etc.
  • Figure 2 describes more precisely the stages of obtaining the consolidated grant
  • Figure 3 describes a device for implementing the proposed technique.
  • the main purpose of the invention is to develop a single application of collection.
  • This unique business application dedicated to the collection includes simple functions of the systems of cashing: possibility to divide or to distribute the payment of an invoice (when the invoice is shared between several customers for example), possibility of deleting articles or to apply discounts on the bill, etc.
  • This cashing application is called generic since it does not include any complex collection functions (which are linked to local, regional or national regulations) and is available for all terminals. a given type. In a particular mode of implementation, the payment terminal manufacturer may select the types or ranges of payment terminals on which the generic application is installed.
  • the cashing application can be implemented in the form of a module, software or hardware, which is in charge of the collection functions at the terminal of the payment terminal.
  • the general principle of the invention is also to implement a generic interface between the payment terminal and the cashing system, to avoid developing particular interfaces, which are often complex and expensive. Indeed, to solve the aforementioned problems, it is also necessary to provide a possibility of data transmission between the collection system and the payment terminal.
  • Such data transmission can be implemented by a physical interface based on either a wired transmission or a wireless transmission.
  • the payment terminal receives data (mainly a transaction transaction donation) and displays this donation in order to allow the customer (the one who settles the transaction amount) to pay (ie generally say to enter a personal identification code, PIN code).
  • the proposed technique does not fundamentally change this way of working.
  • the proposed technique modifies both the way the data is transmitted and the recipient of the transmitted data.
  • the collection systems are para meta ble. They can be set both in terms of electronic display (eg for the appearance of icons or logos that are displayed on the various screens of the system). They can also be set in terms of physical display: the logos and data that are printed on the receipts can be set.
  • the system offers several options for payment of receipts. The proposed technique is based on these possibilities for printing, in addition to the data traditional (store, date, time, logos, product identification, quantities, price per item, total price, tax amounts), consolidated data and converted into a visual symbol. This consolidated data includes, in condensed and standardized form, all the useful data of the receipt (date / time / identification of products, quantity per product, price per product, total amount, tax amounts).
  • This consolidated data is printed on the receipt and is readable by the payment terminal.
  • the transmission of useful data for the payment terminal collection functions does not require the development of a complex application on the payment terminal and on the collection system.
  • a suitable setting of the cashing system may be sufficient. In certain situations in which such an impression is not possible, it is only necessary to develop a specific application for the collection system and not for the terminal, which is much less expensive.
  • the data is always intended for the payment terminal, but the data is no longer transmitted, as traditionally, to a payment application (ie a secure application responsible for validating payment), but to the payment application (generic) of the payment terminal which is in charge of processing transaction data. It is the cashing application that then communicates with the payment application to perform the transaction (s) (for example, several separate transactions when the invoice amount is to be divided among several payers).
  • a payment application ie a secure application responsible for validating payment
  • the payment application generator of the payment terminal which is in charge of processing transaction data. It is the cashing application that then communicates with the payment application to perform the transaction (s) (for example, several separate transactions when the invoice amount is to be divided among several payers).
  • the proposed technique comprises, from the point of view of the payment terminal:
  • a step 20 of formatting the consolidated data by an application for collection of said payment terminal, issuing a digital invoice (FactN); a display stage 30, by said cashing application, of said digital bill (FactN);
  • At least one transmission step 40 to a payment application AppP of said payment termi, at least one data representative of a sum to be paid S as a function of at least one element E of said digital factu re.
  • the installation stage comprises a step of obtaining an image representative of the invoice to be adjusted, for example by means of a digital sensor installed on said terminal.
  • the image is the consolidated data.
  • the formatting of the consolidated data then comprises an optical character recognition step that delivers the data of the invoice.
  • the pre-existing support is not in the form of an invoice, but for example a screen, such as the screen of the cash register, on which the consolidated data is displayed.
  • the consolidated data is in the form of an audio signal emitted by the collection system.
  • a Q.Rsec. Code 4 or 10 is used to record the consolidated data (the data item containing the paytable data).
  • Other types of Q.R code may also be used. This is a simple presentation. The advantage of this type of Q.R code is that from 67 (version 4) to 395 (version 10) alphanumeric characters (a bit equivalent can also be calculated).
  • version code 40 may also be used.
  • the objective in this embodiment, is not to store, in the code to two dimensions, a link (an address) to which the payment terminal cashing application will be redirected to obtain the useful data.
  • the goal is to store in the code the useful data.
  • the storage capacity of such a code is limited, as is the capacity of the collection system to generate such codes, an additional problem must be solved: how to do when the amount of data exceeds that of the code .
  • the first is to compress the data that must be inserted in the code; this compression, in this particular embodiment is carried out either with a Baudot coding or with an adaptive Huffman coding.
  • Baudot coding is that the payload is always distributed in the same sequence comprising the article (including letters), a possible quantity and a price (including numbers).
  • Baudot coding which includes a 5-bit character encoding is interesting in this situation because the succession of useful data is predictable. Thus, the storage capacity of the code is greatly increased.
  • the second solution is to print as much code as necessary. For example, if the capacity of the first code is exceeded, a second code is printed to provide the missing data. Code printing continues as long as data needs to be added.
  • At least one code including the payload is printed on the receipt.
  • the proposed technique comprises:
  • obtaining this consolidated data is implemented by the following steps: scan (11) of the receipt by the payment terminal (the use of the scan function is authorized for the cashing application) using a barcode reader;
  • decoding (12) the obtained code optionally including a step of decompressing data if necessary;
  • the cashing features of the generic application can thus be implemented.
  • These functionalities can for example be functions of division, distribution, reduction of amount, loyalty (credit card loyalty), etc.
  • these functionalities are simple and do not interfere with the complex functions of the collection system (such as for example the calculation of VAT amount, transaction logging, etc.).
  • the implementation of the payment is ordered from the payment terminal cashing application.
  • the cashing application transmits to the payment application the data required for payment (i.e., at least the amount), and Payment application is responsible for performing the necessary transactions for payment (verification of the PIN, obtaining banking authorization, etc.) up to the printing of an expense report per meal. If the consumer decides to pay in cash or via any other means of payment (restaurant titles for example), the application offers the possibility to note it in order to calculate the total amount to be paid.
  • the proposed technique when the functions offered by the cashing application are more complex, also comprises, from the point of view of the payment terminal, a complementary printing step, with the aid of a payment terminal printer, a summary data item, also aggregated, in the form of a two-dimensional code (QR Code), on a payment ticket.
  • the payment ticket is the duplicate ticket that is kept by the merchant.
  • the code which is printed in a complementary manner can be read by the collection system, for example by means of a hand shower, in order to take into account the complex collection operation carried out from the payment terminal.
  • This step of printing the two-dimensional code is preceded by a step of calculating the necessary data.
  • the two-dimensional code data in addition to being compressed, is also encrypted. More particularly, the data is encrypted using a public key available through the cashing system. The cashing system encrypts the data once it has been compressed (if compression is implemented).
  • the proposed technique is based on the ability of the collection system to restore (or print) a consolidated data that includes all the data useful to the payment terminal cashing module.
  • This useful data includes at least the identification of the articles.
  • these useful data also include the number of items, the amount of these items and possible tax amounts, or even tax codes.
  • the POS system may take the form of a so-called “smart" cash register, which can be set up to perform invoice printing according to local or regional regulations and other regulations. in accordance with the merchant's presentation requirements.
  • the collection system may also take the form of a computer system, more or less decentralized, in which cash registers, slaves, are connected to a cashing server via a communication network. This case may apply, for example, to distribution networks (franchised) or to large stores or businesses in which the cash registers are connected in a network. In this case, the setting can be made for all cash registers, at the server of cashing.
  • the system is therefore set to return the consolidated data (or a coded and / or encrypted form of the consolidated data) on the invoice, when printing it or on any other suitable medium: for example a bar code may be imme diated at the merchant's request when the customer wishes to pay the invoice.
  • the consolidated data is printed on the invoice itself.
  • the invoice may also be a receipt, a box or any other suitable support.
  • the collection is carried out directly at the table: 1.
  • the server types the number of the table at the collection system.
  • the cashing system prints the ticket with the details of the bill and the total;
  • the printed Q.R code contains the addition information in the form "Name of the dish” "Quantity” “Price” "VAT", each item being separated by a separating symbol;
  • the server arrives at the table to proceed with the payment with its electronic payment terminal
  • the server scans the code (s) Q.R.
  • the terminal then recreates the whole of the addition with the data included in the code Q.R;
  • the server can ask the person P2 what it is consumed and then on.
  • the "Remaining Payable" total is automatically updated at the end of each subtotal paid;
  • the subtotal must therefore be zero to validate that all consumers of a table have paid all of their consumptions.
  • the payment terminal equipped with a generic cashing application within the meaning of the present technique, associated with a simplified obtaining of the useful data relating to the purchase allow the merchant to have a payment terminal useful in the case of collection processing located at different locations from where the main cash register system is located.
  • a simplified architecture of a payment terminal capable of implementing the described technique is presented.
  • a terminal comprises a memory 41, a processing unit 42 equipped for example with a microprocessor, and driven by the computer program 43, implementing at least part of the method as described.
  • the technique described is implemented in the form of a software application.
  • the described technique is implemented in a purely hardware form, using processors and interfaces specially created for this purpose, for example in a secure payment terminal.
  • Such a terminal comprises: means for capturing at least one piece of data representative of an invoice to be settled, said consolidated data item;
  • the terminal may also include cryptographic processing modules for encrypting and decrypting data.
  • Such modules and components constitute the means implemented to perform the necessary operations in connection with the present technique.
  • Such means may be in a hardware form, for example processors or microprocessors of the FPGA type, or in a software form or in a combination of these forms.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Marketing (AREA)
  • Cash Registers Or Receiving Machines (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention se rapporte à une méthode de traitement de données transactionnelles, par l'intermédiaire d'un terminal de paiement. Selon l'invention, une telle méthode de traitement comprend: - une étape de capture (10), à partir d'un support préexistant (FR), d'au moins une donnée représentative d'une facture à régler (DRAGR), dite donnée consolidée; - une étape de formatage (20) de la donnée consolidée, par une application d'encaissement dudit terminal de paiement, délivrant une facture numérique (FactN); - une étape d'affichage (30), par ladite application d'encaissement, de ladite facture numérique (Fact N); - au moins une étape de transmission (40), à une application de paiement dudit terminal de paiement (AppP), d'au moins une donnée représentative d'une somme à payer (S) en fonction d'au moins un élément (E) de ladite facture numérique, dite donnée transactionnelle.

Description

Méthode de traitement de données transactionnelles, terminal, serveur et programmes d'ordinateur correspondants.
1. Domaine de l'invention
L'invention se rapporte au domaine des dispositifs de paiement. Plus particulièrement, l'invention se rapporte à un dispositif de paiement qui dispose de capacités d'encaissement.
2. Art Antérieur
Des terminaux de paiement sont désormais majoritairement utilisés dans les commerces pour effectuer les règlements des achats. Les commerçants plébiscitent ces terminaux de paiement car ils offrent un degré de sécurisation de transaction supérieur à d'autres moyens de paiement (tels que les chèques) et qu'ils permettent d'éviter les inconvénients liés à la possession de trop grande quantité d'argent liquide.
Ainsi, le terminal de paiement est devenu l'accessoire privilégié du commerçant. En revanche, dans certaines situations, le terminal de paiement n'est pas encore tout à fait adapté au besoin du commerçant dû à un manque de fonctionnalité métiers. Par exemple, afin de faciliter les opérations d'encaissement, des commerçants réclament une solution d'encaissement intégrée avec le terminal de paiement. Par solution d'encaissement, on comprend d'une part une intégration et une communication entre le terminal de paiement et une caisse enregistreuse intelligente et d'autre part un respect de normes en vigueur relatives au paiement (de telles normes sont généralement bâties pour un pays donné).
Ainsi, une intégration terminal de paiement/caisse enregistreuse dépend du système d'encaissement (par exemple la caisse enregistreuse), du terminal de paiement et n'est généralement valable que dans un pays. Ainsi, si l'on souhaite interfacer un type de terminal de paiement avec un type de système d'encaissement, il est nécessaire de le faire pays par pays ou région par région, ce qui pose des problèmes de coût.
De plus, interfacer un système d'encaissement et un terminal de paiement requiert des compétences de développement logiciel, tant au niveau du système d'encaissement qu'au niveau du terminal de paiement. En conséquence, ceci nécessite une gestion de configuration complexe, car il est nécessaire de maintenir de nombreuses versions différentes de logiciel. Ceci est donc également long et coûteux.
Il existe donc un besoin de fournir une solution aux problèmes de coûts et de faisabilité d'intégration afin de fournir au terminal de paiement des fonctionnalités d'encaissement pour faciliter le quotidien des commerçants.
3. Résumé de l'invention
La technique proposée ne présente pas ces inconvénients de l'art antérieur. Plus particulièrement, la technique proposée se rapporte à une méthode de traitement de données transactionnelles, par l'intermédiaire d'un terminal de paiement.
La méthode proposée se différencie par le fait qu'elle comprend :
une étape de capture, à partir d'un support préexistant, d'au moins une donnée représentative d'une facture à régler, dite donnée consolidée ;
une étape de formatage de la donnée consolidée, par une application d'encaissement dudit terminal de paiement, délivrant une facture numérique ; une étape d'affichage, par ladite application d'encaissement, de ladite facture numérique ;
au moins une étape de transmission, à une application de paiement dudit terminal de paiement, d'au moins une donnée représentative d'une somme à payer en fonction d'au moins un élément de ladite facture numérique, dite donnée transactionnelle.
Ainsi, la technique proposée permet d'obtenir des données relatives à la facture sans avoir besoin de modifier le fonctionnement du système d'encaissement (qui peut être une caisse enregistreuse). En effet, en effectuant une capture à partir d'un support existant (comme un ticket de caisse ou une facture imprimée, mais également un écran du système d'encaissement), il n'est pas nécessaire de prévoir un développement spécifique du côté du système d'encaissement.
Selon un mode de réalisation particulier, ladite étape de capture de ladite donnée consolidée comprend :
- au moins une étape d'obtention d'un code en deux dimensions préalablement imprimé sur une facture ; une étape de décodage dudit code en deux dimensions délivrant ladite donnée consolidée ;
Ainsi, la seule obtention d'un code en deux dimensions, puis le décodage de la don née pe rmet de tra nsmettre les don nées nécessa i res à l'a pp lication d'encaissement du terminal.
Selon un mode de réa lisation particulier, ladite étape de ca pture de ladite donnée consolidée comprend en outre, postérieurement à ladite étape de décodage dudit code en deux dimensions, une étape de décompression des données dudit code à deux dimensions.
Ainsi, comme les données sont compressées sur le code en deux dimensions, il est possi ble de tra nsmettre, su r le code, pl us de don nées q ue ce l les q u'i l est normalement possible de transmettre par l'intermédiaire de ce type de code.
Selon une caractéristique particulière, ladite étape de capture de ladite donnée consolidée comprend en outre, postérieurement à ladite étape de décodage dudit code en deux dimensions, une étape de déchiffrement des données dudit code à deux dimensions.
Ainsi, les données consolidées ne sont pas déchiffrables par n'importe quelle application de capture de code à barre. I l n'est pas non plus possible, pour un client indélicat, de frauder en modifiant le contenu du code à barre.
Selon un mode de réalisation particulier, ladite méthode comprend en outre, postérieurement à la transmission, à ladite application de paiement dudit terminal de paiement, de ladite au moins une donnée représentative d'une somme à payer :
une étape de prise de contrôle dudit terminal de paiement par ladite application de paiement ;
- u ne éta pe de m ise e n œuvre d' u ne tra nsaction de pa ie me nt pa r ladite application de paiement ;
une étape de fourniture, à ladite application d'encaissement, d'un résultat de ladite transaction de paiement ;
une étape d'intégration, par ladite application d'encaissement, dudit résultat de ladite transaction de paiement. Ainsi, il n'y a pas de trou de sécurité dans le traitement de ces données transactionnelles.
Dans un autre mode de réalisation, la technique proposée peut également prendre la forme d'un terminal de paiement comprenant des moyens de traitement de données transactionnelles. Ces moyens de traitement de données transactionnelles comprennent :
des moyens de capture d'au moins une donnée représentative d'une facture à régler, dite donnée consolidée ;
des moyens de formatage de la donnée consolidée, par une application d'encaissement dudit terminal de paiement, délivrant une facture numérique ; des moyens d'affichage, par ladite application d'encaissement, de ladite facture numérique ;
des moyens de transmission, à une application de paiement dudit terminal de paiement, d'au moins une donnée représentative d'une somme à payer en fonction d'au moins un élément de ladite facture numérique, dite donnée transactionnelle.
Selon une implémentation préférée, les différentes étapes des procédés selon l'invention sont mises en œuvre par un ou plusieurs logiciels ou programmes d'ordinateur, comprenant des instructions logicielles destinées à être exécutées par un processeur de données d'un module relais selon l'invention et étant conçu pour commander l'exécution des différentes étapes des procédés.
En conséquence, l'invention vise aussi un programme, susceptible d'être exécuté par un ordinateur ou par un processeur de données, ce programme comportant des instructions pour commander l'exécution des étapes d'un procédé tel que mentionné ci-dessus.
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'invention vise aussi un support d'informations lisible par un processeur de données, et comportant des instructions d'un programme tel que mentionné ci- dessus.
Le support d'informations 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, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur.
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations 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.
Selon un mode de réalisation, l'invention est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels.
Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Un tel composant logiciel est exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, routeur, etc.) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc.).
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, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une ca rte à mémoire, une carte électronique pour l'exécution d'un micrologiciel (firmware), etc.
Chaque composante du système précédemment décrit met bien entendu en œuvre ses propres modules logiciels.
Les différents modes de réa lisation mentionnés ci-dessus sont combinables entre eux pour la mise en œuvre de l'invention.
4. Liste des figures
D'a utres ca racté ristiq ues et ava ntages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de sim ple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels :
la figure 1 présente un synoptique de la technique proposée ;
la figure 2 décrit pl us préciséme nt les éta pes d'obtention de la don née consolidée ;
la figure 3 décrit un dispositif pour la mise en œuvre de la technique proposée.
5. Description
5.1. Rappel du principe général de l'invention
Comme l'objectif est de fou rni r, a u te rmi na l de pa iement, des fonctions d'encaisse me nt (de caisse en registreuse), le pri nci pe de l'i nvention consiste à développer une unique application d'encaissement. Cette unique application métier dédiée à l'encaissement comprend des fonctions simple des systèmes d'encaissement : possibilité de diviser ou de répartir le paiement d'une facture (lorsque la facture est partagée entre plusieurs clients par exemple), possibilité de supprimer des articles ou d'appliquer des réductions sur la note, etc. Cette application d'encaissement est dite générique puisqu'elle ne com prend d' une pa rt pas de fonctions d'encaissement complexes (qui sont liées à des réglementations locales, régionales ou nationales) et qu'elle est disponible pour tous les terminaux d'un type donné. Dans un mode de mise en œuvre particulier, le constructeur de terminaux de paiement peut sélectionner les types ou les gammes de terminaux de paiement sur lesquels l'application générique est insta llée. Pour les constructeurs de terminaux de paiement qui intègrent des processeurs qui ne varient pas ou peu, l'application peut facilement être déployée sur de no m b re uses ga m m es o u de no m b re ux types de te rm i na ux de pa ie me nt. L'application d'encaissement peut être mise en œuvre sous la forme d'un module, logiciel ou matériel, q ui est en cha rge des fonctions d'encaissement a u sei n du terminal de paiement.
Le principe général de l'invention consiste également à mettre en œuvre un interfaçage générique entre le terminal de paiement et le système d'encaissement, pour éviter de développer des interfaces particulières, qui sont souvent complexes et coûteuses. En effet, pour permettre de résoudre les problèmes susmentionnés, il est également nécessaire de prévoir une possibilité de transmission de données entre le système d'encaissement et le terminal de paiement.
Traditionnel lement, une tel le tra nsmission de données peut être mise en œuvre par un interfaçage physique basé soit sur une transmission filaire soit sur une transmission sans fil. Le terminal de paiement reçoit des données (principalement une don née relative a u monta nt de la tra nsaction) et affiche cette don née afi n de permettre au client (celui qui règle le montant de la transaction) de payer (c'est-à-dire généralement de saisir un code personnel d'identification, code PIN).
La technique proposée ne change pas fondamentalement cette manière de fonctionner. La technique proposée, cependant, modifie d'une part la manière dont les données sont transmises et d'autre part, le destinataire des données transmises.
Pour ce qui est de la manière dont les données sont transmises, on utilise une tech niq ue q ui ne nécessite pas de cha ngements ta nt a u nivea u d u te rmi na l de paiement que du système d'encaissement. Pour ce faire, on met à profit la capacité du système d'encaissement à imprimer un ticket de caisse.
En effet, les systèmes d'encaissement sont para métra bles. I ls peuvent être paramétrés à la fois en termes d'affichage électronique (par exemple pour l'apparence des icônes ou des logos qui sont affichés sur les différents écrans du système). I ls peuvent également être paramétrés en termes d'affichage physiques : les logos et les données qui sont imprimées sur les tickets de caisse sont paramétrables. Le système offre plusieurs possibilités de pa ramétrage pour les tickets de caisse. La technique proposée se base sur ces possibilités pour imprimer, en sus des données traditionnelles (magasin, date, heure, logos, identification de produits, quantités, prix par article, prix total, montants des taxes), une donnée consolidée et convertie en un symbole visuel. Cette donnée consolidée comprend, sous une forme condensée et standardisée, l'intégralité des données utiles du ticket de caisse (date/heure/identification des produits, quantité par produit, prix par produit, montant total, montants des taxes). Cette donnée consolidée est imprimée sur le ticket de caisse et est lisible par le terminal de paiement. Ainsi, la transmission des données utiles, pour les fonctions d'encaissement du terminal de paiement, ne nécessite pas de développer une application complexe sur le terminal de paiement et sur le système d'encaissement. Un paramétrage adapté du système d'encaissement peut être suffisant. Dans certaines situations dans lesquelles une telle impression n'est pas possible, il n'est nécessaire que de développer une application spécifique pour le système d'encaissement et non pas pour le terminal, ce qui est nettement moins coûteux.
Pour ce qui est du destinataire des données transmises par le système d'encaissement : les données sont toujours destinées au terminal de paiement, mais les données ne sont plus transmises, comme traditionnellement, à une application de paiement (i.e. une application sécurisée chargée de valider le paiement), mais à l'application d'encaissement (générique) du terminal de paiement qui est en charge du traitement de données transactionnelles. C'est l'application d'encaissement qui communique ensuite avec l'application de paiement pour effectuer la ou les transactions (par exemple plusieurs transactions distinctes lorsque le montant de la facture doit être divisé entre plusieurs payeurs).
Plus précisément décrit en relation avec la figure 1, la technique proposée comprend, du point de vue du terminal de paiement :
une étape de capture, à partir d'un support préexistant, 10 d'au moins une donnée représentative DRAGR d'une facture à régler FR, dite donnée consolidée ;
une étape de formatage 20 de la donnée consolidée, par une application d'encaissement dudit terminal de paiement, délivrant une facture numérique (FactN) ; une éta pe d'affichage 30, par ladite application d'encaissement, de ladite facture numérique (FactN) ;
au moins une étape de transmission 40, à une application de paiement AppP dudit termi na l de paiement, d'a u moins une donnée représentative d'une som me à payer S en fonction d'a u moi ns u n élément E de ladite factu re numérique.
Dans un mode de réa lisation pa rticulier de l'invention, l'éta pe de ca pture comprend une étape d'obtention d'une image représentative de la facture à régler, par le biais par exemple d'un capteur numérique installé sur ledit terminal. Dans ce cas, l'image est la donnée consolidée. Le formatage de la donnée consolidée comprend alors une étape de reconnaissance optique de caractères délivra nt les données de la facture. Dans d'autres modes de réalisation, le support préexistant ne se présente pas sous la forme d'une facture, mais par exemple d'un écran, tel que l'écran de la caisse enregistreuse, sur laquelle la donnée consolidée est affichée. Dans un autre mode de réalisation, la donnée consolidée se présente sous la forme d'un signal audio, émis par le système d'encaissement.
Par la suite, on présente un mode de réa lisation de l'invention. Ce mode de réalisation se base sur une matérialisation particulière de la donnée consolidée. Il va de soi que toute autre matérialisation textuelle ou graphique de la donnée consolidée peut être préférée à la présente technique sans qu'elle puisse être considérée comme n'étant pas comprise dans le champ de la présente technique.
5.2. Description d'un mode de réalisation
Da ns ce mode de réalisation, on décrit une mise en œuvre de la technique décrite à l'aide de code en deux dimensions. Dans ce mode de réalisation, un Q.R code de ve rsion 4 ou 10 est uti lisé pour enregistrer la donnée consolidée (la donnée contenant les données utiles du ticket de caisse). D'autres type de Q.R code peuvent également être utilisés. Il s'agit ici d'une simple présentation. L'avantage de ce type de Q.R code est q u' i l pe ut sto ke r de 67 (version 4) à 395 (version 10) caractères alphanumériques (un équivalent en bit peut également être calculé).
En fonction des modes de réalisation, un code version 40 peut également être utilisé. L'objectif, dans ce mode de réalisation, n'est pas de stocker, dans le code à deux dimensions, un lien (une adresse) vers lequel l'application d'encaissement du terminal de paiement va être redirigée pour obtenir les données utiles. L'objectif est bien de stocker dans le code les données utiles. Bien entendu, la capacité de stockage d'un tel code étant limitée, tout comme est limitée la capacité du système d'encaissement à générer de tels codes, un problème supplémentaire doit être résolu : comment faire lorsque la quantité de données excède celle du code.
Pour ce faire, dans ce mode de réalisation de l'invention, deux solutions complémentaires sont employées : la première consiste à compresser les données qui doivent être insérées dans le code ; cette compression, dans ce mode de réalisation particulier est réalisée soit avec un codage Baudot, soit avec un codage Huffman adaptatif. L'avantage de l'utilisation du codage Baudot est que les données utiles sont toujours réparties selon la même séquence comprenant l'article (comprenant des lettres), une quantité éventuelle et un prix (comprenant des chiffres). Or le codage Baudot qui comprend un codage de caractères sur 5 bits est intéressant dans cette situation car la succession des données utiles est prévisible. Ainsi, on augment grandement la capacité de stockage du code.
La deuxième solution consiste à imprimer autant de code que nécessaire. Par exemple, si la capacité du premier code est dépassée, un deuxième code est imprimé afin de fournir les données manquantes. L'impression de code continue tant que des données doivent être ajoutées.
Quoi qu'il en soit, dans ce mode de réalisation, au moins un code comprenant les données utiles est imprimé sur le ticket de caisse. Les traitements réalisés par le système d'encaissement s'arrêtent à ce point.
Du point de vue du terminal de paiement, comme exposé en figure 2, la technique proposée comprend :
une étape d'initialisation (00) d'une application d'encaissement ;
une étape d'obtention (10) de la donnée consolidée : dans ce mode de réalisation, l'obtention de cette donnée consolidée est mise en œuvre par les étapes suivantes : scan (11) du ticket de caisse par le terminal de paiement (l'utilisation de la fonction de scan est autorisée pour l'application d'encaissement) à l'aide d'un lecteur de code à barre ;
décodage (12) du code obtenu, comprenant optionnellement une étape de décompression de données si cela est nécessaire ;
enregistrement (13) de la donnée consolidée au sein dudit terminal ; une étape de formatage (20) de la donnée consolidée par ladite application d'encaissement, délivrant un ticket de caisse numérique ;
une étape d'affichage (30), sur l'écran dudit terminal de paiement, du ticket de caisse numérique.
Ainsi, le ticket de caisse est importé au sein du terminal de paiement. Les fonctionnalités d'encaissement de l'application générique peuvent ainsi être mise en œuvre. Ces fonctionnalités peuvent par exemple être des fonctionnalités de division, de répartition, de réduction de montant, de fidélisation (crédit de carte de fidélité), etc. Dans ce mode de réalisation, ces fonctionnalités sont simples et n'interfèrent pas avec les fonctions complexes du système d'encaissement (comme par exemple le calcul de montant de TVA, de journalisation de transactions, etc.).
La mise en œuvre du paiement est commandée à partir de l'application d'encaissement du terminal de paiement. Pour ce faire, lorsqu'un paiement doit être réalisé, l'application d'encaissement transmet, à l'application de paiement, les données nécessaires au paiement (c'est-à-dire, au minimum, le montant), et l'application de paiement se charge d'effectuer les opérations nécessaires au paiement (vérification du PIN, obtention d'autorisation bancaire, etc.) en allant jusqu'à l'impression d'une note de frais par repas. Si le consommateur décide de payer en liquide ou via tout autre moyen de paiement (titres restaurants par exemple), l'application offre la possibilité de le noter afin de calculer le restant total à payer.
Dans un mode de réalisation complémentaire, lorsque les fonctions offertes par l'application d'encaissement sont plus complexes, la technique proposée comprend en outre, du point de vue du terminal de paiement, une étape complémentaire d'impression, à l'aide d'une imprimante du terminal de paiement, d'une donnée récapitulative, également agrégée, sous la forme d'une code en deux dimensions (Q.R Code), sur un ticket de paiement. Le ticket de paiement est le duplicata du ticket qui est conservé par le commerçant. Le code qui y est imprimé de manière complémentaire peut être lu par le système d'encaissement, par exemple à l'aide d'une douchette, afin de prendre en compte l'opération d'encaissement complexe réalisée depuis le terminal de paiement.
Cette étape d'impression du code en deux dimensions est précédée d'une étape de calcul des données nécessaires.
Dans un mode de réalisation complémentaire, en plus d'être compressées, les données du code en deux dimensions sont également chiffrées. Plus particulièrement, les données sont chiffrées à l'aide d'une clé publique disponible par l'intermédiaire du système d'encaissement. Le système d'encaissement chiffre les données une fois qu'elles ont été compressées (si une compression est mise en œuvre).
5.3. Système d'encaissement
Comme exposé préalablement, la technique proposée se base sur la capacité du système d'encaissement à restituer (ou à imprimer) une donnée consolidée qui comprend l'intégralité des données utiles au module d'encaissement du terminal de paiement. Ces données utiles comprennent au moins l'identification des articles. De manière complémentaire, ces données utiles comprennent également le nombre d'articles, le montant de ces articles et des montants de taxes éventuels, voire des codes de taxes.
Le système d'encaissement, en fonction des modes, peut prendre la forme d'une caisse enregistreuse dite « intelligente », qui peut être paramétrée pour effectuer des impressions de factures conformes d'une part à des réglementations locales ou régionales et d'autres part conformes à des exigences de présentation du commerçant. Le système d'encaissement peut également prendre la forme d'un système informatique, plus ou moins décentralisé, dans lequel des caisses enregistreuses, esclaves, sont connectées à un serveur d'encaissement par l'intermédiaire d'un réseau de communication. Ce cas peut par exemple s'appliquer à des réseaux de distribution (franchisés) ou à des magasins ou des commerces de grande taille dans lesquelles les caisses enregistreuses sont reliées en réseau. Dans ce cas, le paramétrage peut être réalisé pour l'ensemble des caisses enregistreuses, au niveau du serveur d'encaissement.
Le système est donc paramétré pour restituer la donnée consolidée (ou une forme codée et/ou chiffrée de la donnée consolidée) sur la facture, lors de l'impression de celle-ci ou sur tout autre support adapté : par exemple un code à barre peut être im pri mé à la dema nde du commerça nt lorsque le client i ndique vouloi r régler sa facture. Da ns ce cas, la donnée consolidée est imprimée à pa rt de la facture elle- même. Bien entendu, en fonction des commerces et des modes de réalisation, la facture peut éga lement être un ticket de caisse, une ca rte ou tout autre support adapté.
5.4. Description d'un cas d'usage
O n présente ci-après u n cas d' usage de la tech niq ue proposée da ns u n restaurant ou un bar permettant de réaliser des séparations d'additions basées sur le nombre de personnes et leurs consommations. Sur ce marché, la gestion de l'addition est relativement complexe car elle nécessite de manipuler plusieurs types de moyens de paiement (monnaie, billets, carte bleue, titre restaurants, avoirs...) et ce dans un contexte d'environnements particulier (debout, à la table des consommateurs) et enfin dans un contexte de temps serré puisqu'il s'agit souvent d'environnement comprenant des pics d'affluence.
Lorsqu'une ta ble de ma nde la sé pa ratio n de l'add itio n, la situation se complexifie, surtout quand les consommateurs souhaitent payer uniquement ce qu'ils ont consommé (vs division par le nom bre de consommateurs). Les impacts étudiés sont de plusieurs ordres :
temps de calcul long, nécessita nt a u serveur de rester un long moment à la table pour effectuer l'encaissement ;
temps d'attente des autres tables pour commander ou payer ;
erreur de calcul donnant, en fin de service, une erreur de caisse qu'il faut gérer via de nombreux recomptage.
Au contraire grâce à la méthode de traitement de données transactionnelles de la présente technique, l'encaissement est réalisé directement à table : 1. Une fois l'addition demandée par le consommateur, le serveur tape le numéro de la table au niveau du système d'encaissement. Le système d'encaissement imprime le ticket avec le détail de l'addition et le total ;
2. Sur ce même ticket, un code Q.R est imprimé. Dans le cas où les informations à ajouter sont trop nombreuses, il est possible d'imprimer plusieurs codes Q.R (représentant l'addition totale) ;
3. Le code Q.R imprimé contient les informations de l'addition sous la forme « Nom du plat » « Quantité » « Prix » « TVA », chaque donnée étant séparée par un symbole de séparation ;
4. Une fois l'addition déposée sur la table et la demande de séparation faite par le consommateur, le serveur arrive à la table pour procéder au paiement avec son terminal de paiement électronique ;
5. En utilisant le lecteur de code barre de son terminal de paiement électronique, le serveur scanne le ou les code(s) Q.R. Le terminal recréé alors l'ensemble de l'addition avec les données comprises dans le code Q.R ;
6. Une interface permet alors de faire la séparation de l'addition : le serveur demande à la personne PI ce qu'il/elle a mangé et en cochant ses consommations. Une fois que la sélection est faite, alors il est possible de sélectionner le bouton « Sous-total et Paiement » pour procéder au paiement (quel que soit le type de paiement) ;
7. Ensuite, le serveur peut demander à la personne P2 ce qu'elle est a consommé et ensuite de suite. Le total « Restant à Payer » est automatiquement mis à jour à la fin de chaque sous-total payé ;
8. À la fin du paiement, le sous-total donc doit être à zéro pour valider que tous les consommateurs d'une table ont bien payé l'ensemble de leurs consommations.
Il est possible d'imprimer une note de frais à la fin de chaque sous total payé/paiement à la demande du consommateur.
Ainsi, le terminal de paiement équipé d'une application générique d'encaissement, au sens de la présente technique, associé à une obtention simplifiée des données utiles relatives à l'achat permettent au commerçant de disposer d'une terminal de paiement utile dans le cas de traitement d'encaissement localisés à des endroits différents de cel ui où se trouve le système d'encaissement princi pa l du commerce.
5.5. Autres caractéristiques et avantages
On présente, en relation avec la figure 3, une architecture simplifiée d'un terminal de paiement apte à mettre en œuvre la technique décrite. Un tel terminal comprend une mémoire 41, une unité de traitement 42 équipée par exemple d'un microprocesseur, et pilotée par le programme d'ordinateur 43, mettant en œuvre au moins une partie du procédé tel que décrit. Dans au moins un mode de réalisation, la technique décrite est mise en œuvre sous la forme d'une application logicielle. Dans un autre mode de réalisation, la technique décrite est mise en œuvre sous une forme purement matérielle, à l'aide de processeurs et d'interface spécialement créés à cet effet, par exemple dans un terminal de paiement sécurisé. Un tel terminal comprend : des moyens de capture d'au moins une donnée représentative d'une facture à régler, dite donnée consolidée ;
des moye ns de formatage de la donnée consolidée, pa r une a pplication d'encaissement dudit terminal de paiement, délivrant une facture numérique ; des moyens d'affichage, par ladite application d'encaissement, de ladite facture numérique ;
des moyens de transmission, à une application de paiement dudit terminal de paiement, d'au moins une donnée représentative d'une som me à payer en fonction d'a u moi ns un élément de ladite facture numérique, dite don née transactionnelle.
Ces moyens sont pilotés par le microprocesseur, à l'aide du programme chargés da ns la mémoi re du termina l. En fonction des modes de réa lisation, le termi na l co m p re n d é g a l e m e n t d ' a u t re s m oye n s, comme des modulés de transmission/réception de données, permettant de réaliser des échanges avec un système d'encaissement, comme des moyens d'impression de codes à deux dimensions comprenant des données de compte rendu de transactions effectuées par l'intermédiaire dudit terminal. Le terminal peut également comprendre des modules de traitement cryptographique pour le chiffrement et le déchiffrement des données. De tels modules et composants constituent les moyens mis en œuvre pour effectuer les opérations nécessaires en lien avec la présente technique. De tels moyens peuvent se présenter sous une forme matérielle, par exemple des processeurs ou microprocesseurs de type FPGA, ou encore sous une forme logicielle ou sous une combinaison de ces formes.

Claims

REVENDICATIONS
Méthode de traitement de données transactionnelles, par l'intermédiaire d'un terminal de paiement, caractérisé en ce que ladite méthode de traitement comprend :
une étape de capture (10), à partir d'un support préexistant (FR), d'au moins une donnée représentative d'une facture à régler (DRAG ), dite donnée consolidée ;
une étape de formatage (20) de la donnée consolidée, par une application d'encaissement dudit terminal de paiement, délivrant une facture numérique (FactN) ;
une étape d'affichage (30), par ladite application d'encaissement, de ladite facture numérique (FactN) ;
au moins une étape de transmission (40), à une application de paiement dudit terminal de paiement (AppP), d'au moins une donnée représentative d'une somme à payer (S) en fonction d'au moins un élément (E) de ladite facture numérique, dite donnée transactionnelle.
Méthode de traitement selon la revendication 1, caractérisé en ce que ladite étape de capture de ladite donnée consolidée comprend :
au moins une étape d'obtention d'un code en deux dimensions préalablement imprimé sur une facture ;
une étape de décodage dudit code en deux dimensions délivrant ladite donnée consolidée ;
Méthode de traitement selon la revendication 2, caractérisé en ce que ladite étape de capture de ladite donnée consolidée comprend en outre, postérieurement à ladite étape de décodage dudit code en deux dimensions, une étape de décompression des données dudit code à deux dimensions. Méthode de traitement selon la revendication 2, caractérisé en ce que ladite étape de capture de ladite donnée consolidée comprend en outre, postérieurement à ladite étape de décodage dudit code en deux dimensions, une étape de déchiffrement des données dudit code à deux dimensions.
Méthode de traitement selon la revendication 1, caractérisé en ce qu'il comprend en outre, postérieurement à la transmission, à ladite application de paiement dudit terminal de paiement, de ladite au moins une donnée représentative d'une somme à payer :
u ne éta pe de prise de contrôle dudit terminal de paiement par ladite application de paiement ;
une étape de mise en œuvre d'une transaction de paiement par ladite application de paiement ;
une étape de fourniture, à ladite application d'encaissement, d'un résultat de ladite transaction de paiement ;
une étape d'intégration, par ladite application d'encaissement, dudit résultat de ladite transaction de paiement.
Termina l de paiement comprenant des moyens de traitement de données transactionnelles comprenant :
des moyens de capture (10), à partir d'un support préexistant (FR), d'au moins une donnée représentative d'une facture à régler (DRAG ), dite donnée consolidée ;
des moyens de formatage (20) de la donnée consolidée, par une application d'encaissement dudit terminal de paiement, délivrant une facture numérique (FactN) ;
des moyens d'affichage (30), par ladite application d'encaissement, de ladite facture numérique (FactN) ;
des moyens de transmission (40), à une application de paiement dudit terminal de paiement (AppP), d'au moins une donnée représentative d'une somme à payer (S) en fonction d'au moins un élément (E) de ladite facture numérique, dite donnée transactionnelle.
Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution de la méthode selon l'une des revendications 1 à 5, lorsqu'elle est exécuté sur un ordinateur.
EP14777571.2A 2013-09-27 2014-09-26 Méthode de traitement de données transactionnelles, terminal, serveur et programmes d'ordinateur correspondants Ceased EP3050034A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1359350A FR3011366B1 (fr) 2013-09-27 2013-09-27 Methode de traitement de donnees transactionnelles, terminal, serveur et programmes d’ordinateur correspondants.
PCT/EP2014/070704 WO2015044393A1 (fr) 2013-09-27 2014-09-26 Méthode de traitement de données transactionnelles, terminal, serveur et programmes d'ordinateur correspondants

Publications (1)

Publication Number Publication Date
EP3050034A1 true EP3050034A1 (fr) 2016-08-03

Family

ID=50424340

Family Applications (1)

Application Number Title Priority Date Filing Date
EP14777571.2A Ceased EP3050034A1 (fr) 2013-09-27 2014-09-26 Méthode de traitement de données transactionnelles, terminal, serveur et programmes d'ordinateur correspondants

Country Status (6)

Country Link
US (1) US10504078B2 (fr)
EP (1) EP3050034A1 (fr)
BR (1) BR112016006647A2 (fr)
CA (1) CA2921110C (fr)
FR (1) FR3011366B1 (fr)
WO (1) WO2015044393A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108256929A (zh) * 2016-12-28 2018-07-06 航天信息股份有限公司 一种基于二维码的电子***开具方法及***

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090108080A1 (en) * 2007-10-31 2009-04-30 Payscan America, Inc. Bar coded monetary transaction system and method
CN102164202A (zh) * 2010-02-22 2011-08-24 上海博路信息技术有限公司 一种手机扫描条码的家庭账单支付方法
US8345981B2 (en) * 2009-02-10 2013-01-01 Kofax, Inc. Systems, methods, and computer program products for determining document validity
US20130018715A1 (en) * 2011-07-18 2013-01-17 Tiger T G Zhou Facilitating mobile device payments using product code scanning to enable self checkout
US20130146659A1 (en) * 2011-07-18 2013-06-13 Dylan T X Zhou Wearable personal digital device for facilitating mobile device payments and personal use

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE4326756C1 (de) * 1993-08-10 1994-09-08 Ekkehard Dr Stephan Bestell- und Abrechnungsanlage
US7457767B1 (en) * 2000-10-05 2008-11-25 International Business Machines Corporation Pay at the table system
US6993507B2 (en) * 2000-12-14 2006-01-31 Pacific Payment Systems, Inc. Bar coded bill payment system and method
US7370794B2 (en) * 2006-03-15 2008-05-13 Fleming Trane Device and system for presenting and facilitating payment of a restaurant bill
US20120290420A1 (en) * 2010-01-28 2012-11-15 Advanced Payment Terminal Corporation Secure Payment Terminal
EP2867838A4 (fr) * 2012-06-29 2016-01-20 Edward Arthur International Llc Dispositif de vérification électronique, son système et son procédé
US8770478B2 (en) * 2013-07-11 2014-07-08 Scvngr, Inc. Payment processing with automatic no-touch mode selection

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090108080A1 (en) * 2007-10-31 2009-04-30 Payscan America, Inc. Bar coded monetary transaction system and method
US8345981B2 (en) * 2009-02-10 2013-01-01 Kofax, Inc. Systems, methods, and computer program products for determining document validity
CN102164202A (zh) * 2010-02-22 2011-08-24 上海博路信息技术有限公司 一种手机扫描条码的家庭账单支付方法
US20130018715A1 (en) * 2011-07-18 2013-01-17 Tiger T G Zhou Facilitating mobile device payments using product code scanning to enable self checkout
US20130146659A1 (en) * 2011-07-18 2013-06-13 Dylan T X Zhou Wearable personal digital device for facilitating mobile device payments and personal use

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ALEX ROLFE: "NACHA issues final guidelines for use of QR codes for bill payment - Payments Cards & Mobile", 25 January 2013 (2013-01-25), XP055748190, Retrieved from the Internet <URL:https://www.paymentscardsandmobile.com/nacha-issues-final-guidelines-for-use-of-qr-codes-for-bill-payment/> [retrieved on 20201109] *
See also references of WO2015044393A1 *

Also Published As

Publication number Publication date
BR112016006647A2 (pt) 2017-08-01
FR3011366B1 (fr) 2020-09-25
US20160239816A1 (en) 2016-08-18
FR3011366A1 (fr) 2015-04-03
WO2015044393A1 (fr) 2015-04-02
CA2921110A1 (fr) 2015-04-02
US10504078B2 (en) 2019-12-10
CA2921110C (fr) 2022-08-09

Similar Documents

Publication Publication Date Title
US11854036B2 (en) Location-based transaction reconciliation management methods and systems
US9805385B2 (en) Subscription bill service, systems and methods
KR100859945B1 (ko) Ｐｏｓ 단말 장치 및 이를 이용한 금융기관의 대출 시스템
EP3316202A1 (fr) Procede et systeme pour reception et/ou l&#39;emission automatique d&#39;informations relatives a des transactions
FR2847701A1 (fr) Systemes electroniques pour le transfert de monnaie
EP3195224A1 (fr) Procédés et dispositifs de gestion de transactions composites
US20150149313A1 (en) Method For Providing A Customer With Information At A Point Of Sale (POS)
WO2016110635A1 (fr) Procédés et dispositifs de commande d&#39;opérations annexes liées a l&#39;exécution de transactions principales
US20160275503A1 (en) Method and system for rewarding parties in a payment transaction via managing circulation of small denominations of currency
EP3142054A1 (fr) Procédé de transmission de données, dispositifs et programmes d&#39;ordinateur correspondants
EP3050034A1 (fr) Méthode de traitement de données transactionnelles, terminal, serveur et programmes d&#39;ordinateur correspondants
EP2824625B1 (fr) Méthode de réalisation de transaction, terminal et programme d&#39;ordinateur correspondant
EP2724305B1 (fr) Procede de transaction dematerialisee
LU501747B1 (fr) Dispositif de traitement de données pour terminal de vente
CH708156A2 (fr) Centrale de regroupement et de gestion de garanties contractuelles et d&#39;autres services commerciaux.
FR3012239A1 (fr) Procede et dispositif permettant de creer et de donner acces a des espaces de vente en ligne personnalises
EP2771856A1 (fr) Service de facturation d&#39;abonnement, systèmes et procédés associés
FR3004832A1 (fr) Procede de gestion d’un compte de fidelite d’un client dans un systeme de vente
WO2006111815A1 (fr) Procede de gestion de credits tels que points de fidelite et dispositif pour sa mise en oeuvre
FR2964767A1 (fr) Procede d&#39;identification de support a microcircuit mis en oeuvre lors de la communication entre un terminal bancaire et ce support

Legal Events

Date Code Title Description
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

17P Request for examination filed

Effective date: 20160223

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

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: 20190416

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

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: 20210120