WO2025119997A1 - Method for recording a digital ticket relating to a transaction - Google Patents

Abstract

The invention is a method for recording a digital ticket relating to a transaction, the method being implemented by computer and characterised in that it comprises the following steps: - generating a digital ticket (14) relating to a transaction; - timestamping the digital ticket (14); - transmitting a transaction identifier (7) from a payment device (2) used for the transaction to a payment terminal (3) used for the transaction; - generating a digital ticket identifier (18) on the basis of the transaction identifier (7); - transmitting the digital ticket (14), the digital ticket identifier (18), and the digital ticket timestamp (15), associated with one another, to a digital ticket database (5).

Description

Method of recording a digital ticket relating to a transaction

The invention relates to the management of digital tickets.

It particularly concerns the dematerialization of “ receipts ”.

When a transaction is settled by a payment device at a payment terminal, a receipt and a payment receipt, both generally referred to as " tickets " in the following, are usually printed and provided to the buyer so that he has information relating to the transaction, in particular payment information.

However, paper tickets of this type are destined to disappear, which eliminates the need for paper and saves the costs of purchasing and maintaining the components used to print these tickets.

To continue providing transaction information to the buyer, an alternative to paper tickets is the generation of digital tickets. Therefore, it is necessary to have a way to transmit a digital ticket, relating to a transaction, to a buyer who has just completed a transaction.

A solution is already known in the state of the art, which consists of sending the generated digital ticket by email or SMS to the user. However, this requires the user to provide their email address or telephone number to the merchant. This is a cumbersome process for the user, which can be subject to errors, and which also presents risks from the point of view of the confidentiality of their data, which can be seen or heard or, with regard to email addresses, be subject to so-called " spear-fishing " attacks. It is also a particularly time-consuming process in the event of a tight flow of buyers at payment points.

Also already known in the art is a solution consisting of making the ticket directly accessible to the user's mobile terminal via near-field communication or QR code. Thus, in particular from documents EP3382628 and KR102444679, a method is known in which, after the transaction, a payment terminal used for this transaction transmits, by near-field communication, to a mobile terminal used for the transaction, a web address allowing the mobile terminal to access the digital ticket relating to the transaction, or even the ticket itself in the case of document EP3382628. However, this requires the buyer to make their payment using a mobile terminal and to have an appropriate mobile application. This process is therefore not suitable for all consumers, who do not all have a smartphone or, for those who do have a smartphone, who do not wish to move around constantly with it, do not wish to settle a transaction with it or do not wish to multiply the mobile applications. This process is also restrictive since it requires the buyer to take out and manipulate their mobile terminal during payment. In addition, this process consumes the mobile terminal's energy as well as its memory. Finally, in general, near -field communication (NFC) is, like the use of QR codes, a process that requires the use of mobile applications that will necessarily be updated regularly to be adapted to all platforms and all versions of these platforms, forcing users to renew their mobile terminals or lose access to their digital tickets.

The invention aims in particular to provide a solution allowing a user to have access to a digital ticket relating to a transaction without the payment experience experienced by the user differing from that associated with paper tickets.

To this end, the invention relates to a method for recording a digital ticket relating to a transaction, implemented by computer, comprising the following steps:

- generation of a digital ticket relating to a transaction;

- timestamp of the digital ticket;

- transmission, from a payment device used for the transaction to a payment terminal used for the transaction, of a transaction identifier;

- generation of a digital ticket identifier from the transaction identifier;

- transmission of the digital ticket, the digital ticket identifier and the digital ticket timestamp, associated with each other, to a digital ticket database.

Thus, it is not necessary to have a mobile terminal or to provide contact details to record the digital ticket relating to the transaction. The payment device directly provides, during payment, the information to the terminal allowing the generation of an identifier for the digital ticket, in particular the transaction identifier, this transaction identifier being specific to the transaction. This identifier recorded within the payment device is known to the user's bank, their digital wallet or the user themselves, so that the user can then access the digital ticket in the database from this identifier.

In particular, the payment device has either a list of pre-recorded random or pseudo-random transaction identifiers and a counter, making it possible to choose a unique identifier from the list for each transaction, or a pseudo-random transaction identifier generator making it possible to generate a unique identifier for each transaction.

The payment process is unchanged from the processes associated with paper tickets. The user experience is even less restrictive since no paper ticket is to be expected at the time of payment, and the user decides for themselves whether or not they want to retrieve their digital ticket from the database, at a later time of their choosing.

Other optional features follow, taken alone or in combination.

Advantageously, the identifier of the digital ticket generated from the transaction identifier is the transaction identifier, or the method comprises a step of hashing the transaction identifier so that the digital identifier generated from the transaction identifier is the result of the hashing.

Thus, the transaction identifier transmitted by the payment device is directly used to generate the digital ticket identifier, without any other information being necessary, or it is hashed. The identifier is advantageously the result of a pseudo-random identifier generator. In the case where the identifier is the result of a pseudo-random identifier generator, the hashing prevents the generator parameters from being found by a third party.

Alternatively, the method comprises the following steps:

- before the generation of the digital identifier, transmission, from the payment device to the payment terminal, of a payment device identifier;

- the generation of the digital ticket identifier from the transaction identifier is carried out by performing a combination between the payment device identifier and the transaction identifier, preferably also by performing a hash of a result of the combination.

Thus, in this case the transaction identifier is not directly transformed into a digital ticket identifier. In fact, the payment device transmits to the payment terminal, in addition to this transaction identifier which is specific to a given transaction, a payment device identifier which remains the same for each transaction since it characterizes the payment device. This could be, for example, the PAN identifier (for " Primary Account Number ") in the case where the payment device is a bank card.

The device identifier is, like the transaction identifier, derived from the payment device owned by the user and also known to the user's bank that issued this payment device, to an electronic wallet of the user or even to the user himself, so that the user can at any time generate the identifier of the digital ticket to find, in the digital ticket database, the digital ticket relating to his transaction.

Combining this payment device identifier with the transaction identifier makes the confidentiality of digital tickets even more secure. In particular, in the case where the transaction identifiers are generated pseudo-randomly, their combination with the payment device identifier prevents a third party from finding the digital ticket identifier solely from the generator parameters. Furthermore, in the case where, upon initialization of the payment device, a specific entity, for which no trust is granted, is responsible for generating the transaction identifiers, combining them with the payment device identifier prevents this entity, which is unaware of the payment device identifier, from being able to find the digital ticket identifiers corresponding to the identifiers it has generated.

Preferably, the method comprises the following steps:

- transmission, from the payment device to the payment terminal, of an encryption key;

- encryption of the generated digital ticket by the encryption key;

and wherein the step of transmitting the digital ticket to the database is the transmission of the encrypted digital ticket.

Thus, the content of the digital ticket is encrypted. This prevents a third party from attempting to obtain information, for example to generate statistics, by performing random queries on the digital ticket database. The encryption key is therefore installed in the payment device when it is initialized, while the corresponding decryption key is known to the user's bank, their digital wallet, or themselves, allowing them to decrypt the content of the digital ticket when the user wishes to access it. This key pair can be an asymmetric key pair. In such a case, the encryption key installed in the device is considered to be the public key, while the decryption key, private, is kept confidential by the bank, the digital wallet, or the user themselves. Alternatively, a single key can be used for encryption and decryption.

Advantageously, the method comprises, before the transmission of the transaction identifier to the payment terminal, a step of selecting, from a list of transaction identifiers of the payment device, one of these identifiers in order to transmit the selected transaction identifier.

Thus, transaction identifiers are pre-recorded in the payment device in the form of a list. Each transaction uses an identifier from this list.

Advantageously, the method comprises:

- a step of counting, by a transaction counter of the payment device, the number of transactions carried out by the payment device, the selection of the identifier being carried out according to this count; or

- selecting, from the list of transaction identifiers of the payment device, the identifier located at one end of the list corresponding to a selection position, then deleting, from the list, this identifier so that the next identifier in the list is in the selection position for a following transaction.

Thus, to avoid selecting the same identifier twice for two separate transactions, two possibilities are offered: in the case of counting, the payment device counter increments its count so that the identifier corresponding to the count is selected. Alternatively, the selected transaction identifier is the one at the end of the list, within the payment device's list of transaction identifiers. This identifier is deleted after the transaction, so that the next identifier in the list is selected for the next transaction. This eliminates the need for a counter.

Advantageously, the method comprises, prior to the transaction, the following steps:

- generation of a list of pseudo-random or random transaction identifiers;

- recording, within the payment device, of this list of transaction identifiers.

Thus, these steps take place when the payment device is initialized, for example when the payment card is manufactured when the payment device is a payment card.

Alternatively, the method comprises, before the transmission of the transaction identifier to the payment terminal, a step of generation, by a generator of pseudo-random transaction identifiers within the payment device, of this transaction identifier.

Thus, a list of transaction IDs is not stored within the payment device in this case. Instead, an ID generator is integrated into the device and generates a transaction ID for each transaction. This generator generates IDs in a pseudo-random manner. The bank, the digital wallet, or the user have the same generator to generate the same IDs, so that the digital tickets can be found in the database.

Advantageously, the method comprises, prior to the transaction, the following steps:

- creation of the pseudo-random transaction identifier generator;

- placement of this generator within the payment device.

Preferably, the method comprises updating, by an ATM and within the payment device, the list of random or pseudo-random transaction identifiers introduced above or the pseudo-random identifier generator introduced above.

Thus, the user can “recharge” his list of transaction identifiers at an ATM.

The invention also relates to a payment method relating to a transaction, comprising, once the payment has been made, the recording of a digital ticket relating to the transaction in accordance with the method described above.

The invention also relates to a method for recovering a digital ticket relating to a transaction, the digital ticket having been recorded in accordance with any one of the preceding claims, comprising the following steps:

- obtaining the transaction identifier;

- generation of a digital ticket identifier from the transaction identifier;

- retrieval, from the digital ticket database, of the digital ticket associated with the generated digital ticket identifier.

Advantageously, in the recovery method, the identifier of the digital ticket is the transaction identifier, or the method comprises a step of hashing the transaction identifier so that the digital identifier is the result of the hashing.

Preferably, the recovery method comprises the following steps:

- before generating the digital identifier, obtaining the payment device identifier,

- generation of the digital ticket identifier by performing a combination between the payment device identifier and the transaction identifier, preferably also by performing a hash of a result of the combination.

Advantageously, the ticket having been encrypted during registration in accordance with the process described above, this recovered digital ticket is decrypted by a decryption key.

The invention also relates to a computer program comprising instructions which, when the program is executed by a computer, cause the latter to implement the steps of the registration method described above, of the payment method described above or of the recovery method described above.

The invention also relates to a computer-readable recording medium comprising instructions which, when executed by a computer, cause the latter to implement the steps of the recording method described above, the payment method described above or the recovery method described above.

The invention also relates to a database of digital tickets, comprising at least one digital ticket recorded in accordance with the method described above, the ticket being associated, in the database, with the identifier of the generated ticket and the timestamp of the ticket.

The invention also relates to a payment device, comprising:

- a payment device identifier;

- a list of transaction identifiers or a generator of pseudo-random transaction identifiers;

- means of transmitting, to a payment terminal, the identifier of the payment device;

- means of transmitting, to a payment terminal, a transaction identifier from the list or a pseudo-random identifier generated by the generator.

Preferably, the device further comprises an encryption key, the transmission means being capable of also transmitting this key.

Advantageously, the device further comprises a transaction counter.

The invention also relates to a payment terminal, comprising automated means capable of:

- receive, from a payment device, a transaction identifier,

- generate an identifier of a digital ticket relating to the transaction from the transaction identifier;

- transmit the digital ticket, associated with the generated digital ticket identifier and the digital ticket timestamp, to a digital ticket database.

Advantageously, the automated means are also capable of:

- receive, from a payment device, a payment device identifier;

- generating a digital ticket identifier by combining the payment device identifier and the transaction identifier, preferably also by hashing a result of the combination.

Brief description of the figures

The invention will be better understood from reading the following description given solely by way of example and with reference to the appended drawings in which:

is a diagram of a system for recording a digital ticket relating to a transaction according to a first embodiment;

is a flowchart of a first mode of implementation of a method of recording a ticket relating to a transaction by the system of the ;

is a diagram of a system for recording a digital ticket relating to a transaction according to a second embodiment;

is a flowchart of a second mode of implementation of the process by the system of the ;

is a diagram of a system for recording a digital ticket relating to a transaction according to a third embodiment;

is a flowchart of a third mode of implementation of the process by the system of the ;

is a diagram of a system for recording a digital ticket relating to a transaction according to a fourth embodiment;

is a flowchart of a fourth mode of implementation of the process by the system of the ;

is a diagram of a system for recording a digital ticket relating to a transaction according to a fifth embodiment;

is a flowchart of a fifth mode of implementation of the process by the system of the ;

is a flowchart of an update process;

is a flowchart of a payment process;

is a flowchart of a digital ticket recovery process.

Detailed description

System 1 of the is a system for recording a digital ticket relating to a transaction. It comprises a payment device 2 in the form of a payment chip card 2. This system 1 also comprises a payment terminal 3. This system 1 also comprises a server 4 and a database 5 of digital tickets.

The term “ payment device ” refers to any device capable of making a payment on the buyer's side, such as a mobile terminal or any connected device, insofar as this payment device is configured to make a payment in combination with a payment terminal. The payment device 2 includes within it an identifier 32 (for “ Primary Account Number ”). It also includes means for making a payment according to protocols known to those skilled in the art and which will not be described in detail.

The payment device 2 further comprises a list 6 of transaction identifiers. These are identifiers of any format for those skilled in the art, for example a random number made readable in hexadecimal format, or in “base64” format. These identifiers are generated beforehand in a pseudo-random or random manner. It is advantageous for these identifiers to be generated in a purely random manner. Indeed, in this case, it is impossible for a malicious third party, from part of a list of these identifiers, to find certain common characteristics between these identifiers making it possible to generate the other identifiers in the list. However, it is simpler and generally sufficient to generate identifiers in a pseudo-random manner, that is to say identifiers sufficiently independent of each other, generated in a sequence of identifiers exhibiting certain properties of chance. The device 2 comprises means 8 for transmitting, to the payment terminal 3, a transaction identifier 7 from the list 6. The card 2 also comprises a recording medium 9 readable by a computer, in particular by a microprocessor, comprising instructions which, when executed by such a microprocessor, cause it to carry out all or part of the steps of the different modes 100, 200, 300, 400, 500 or 600 of the recording method described below, of the payment method 700 described below or of the recovery method 800 described below. To do this, this support 9 comprises a computer program 10. The program 10 comprises instructions which, when the program 10 is executed by a computer, in particular by a microprocessor, lead the latter to implement all or part of the steps of the different modes 100, 200, 300, 400, 500 or 600 of the registration method described below, of the payment method 700 described below or of the recovery method 800 described below.

The term " payment terminal " refers to any device capable of participating in a payment on the seller's side. The payment terminal 3 comprises means of communication 11, with the payment device 2, known to those skilled in the art and which will therefore not be described in detail. The terminal 3 also comprises means for making a payment according to protocols known to those skilled in the art and which will not be described in detail. It also comprises a recording medium 12 readable by a computer, in particular by a microprocessor, comprising instructions which, when executed by such a microprocessor, cause it to implement all or part of the steps of the different modes 100, 200, 300, 400, 500 or 600 of the recording method described below, of the payment method 700 described below or of the recovery method 800 described below. To do this, this support 12 comprises a computer program 13. The program 13 comprises instructions which, when the program 13 is executed by a computer, in particular by a microprocessor, lead the latter to implement all or part of the steps of the different modes 100, 200, 300, 400, 500 or 600 of the registration method described below, of the payment method 700 described below or of the recovery method 800 described below.

In particular, it results from the combination of the conventional means of the payment terminal 3 and the means of the terminal 3 specifically configured to implement the methods described below that the terminal 3 comprises in particular automated means capable of:

- receive, from the payment device 2, a transaction identifier 7,

- generate an identifier 18 of a digital ticket 14 from the transaction identifier 7;

- transmit the digital ticket 14, associated with the identifier 18 of the generated digital ticket and the timestamp 15 of the digital ticket, to the digital ticket database 5.

The database 5 comprises, in the form of data tables, digital tickets relating to transactions, in encrypted form or in clear form. Each of these tickets is associated with an identifier 18 of the digital ticket which is generated in accordance with the modes 100, 200, 300, 400, 500 or 600 of the recording method described below. Each of these tickets is also associated with a timestamp 15 making it possible to determine when the ticket was generated. The server 4 makes it possible to access, read and modify the content of the database 5 of digital tickets. This server 4 therefore comprises means for this purpose which are conventional for those skilled in the art. It comprises means of communication with the payment terminal 3. It also comprises a recording medium 16 readable by a computer, in particular by a microprocessor, comprising instructions which, when executed by such a microprocessor, cause the latter to carry out all or part of the steps of modes 100, 200, 300, 400, 500 or 600 of the recording method described below, of the payment method 700 described below or of the recovery method 800 described below. To do this, this support 16 comprises a computer program 17. The program 17 comprises instructions which, when the program 17 is executed by a computer, in particular by a microprocessor, lead the latter to implement all or part of the steps of the modes 100, 200, 300, 400, 500 or 600 of the registration method described below, of the payment method 700 described below or of the recovery method 800 described below.

The three computer programs 10, 13 and 17 mentioned therefore allow the payment device 2, the payment terminal 3 and the database 5 (via its server 4) to communicate with each other to implement the processes described below.

We will now describe implementation methods 100 to 600 of a method for recording a digital ticket relating to a transaction, implemented by computer, in particular implemented by the automated means of the payment device 2, the payment terminal 3 and the server 4. It will be clear to those skilled in the art which methods can be combined together.

We will first describe mode 100 implemented by system 1 of the .

Step 101, implemented prior to a transaction, is the generation of a list 6 of pseudo-random or random transaction identifiers. It is carried out by an entity external to the system, for example by the bank that issued the payment card 2. A list of “random” identifiers is preferred to a list of “pseudo-random” identifiers for the security reasons mentioned, but the generation of a pseudo-random list is generally simpler.

Step 102 is the recording, within the payment device 2, of this list 6 of transaction identifiers.

A step implemented in parallel is the recording of this list 6 by an entity external to the system, such as the bank that issued the payment device, an electronic wallet of the user or the user himself, within a dedicated database, with a view to recovering the digital ticket subsequently. To do this, if the identifiers have been generated purely randomly, they are transmitted to the external entity, the latter not being able to find them by itself. If, on the other hand, they have been generated pseudo-randomly by a pseudo-random generator, the same generator can be used by the external entity, according to known parameters, to generate the same identifiers.

The following steps take place during the transaction between a buyer, with payment card 2, and a merchant, with payment terminal 3. The buyer makes the payment through the interaction between his card 2 and terminal 3.

Step 103 is the generation of a digital ticket 14 relating to the transaction. This ticket 14 is generated by the payment terminal used 4 for the transaction, possibly in collaboration with a payment cash register of the merchant, according to protocols which are not the subject of the invention. The digital ticket 14 is a receipt which includes the information relating to the transaction such as the items purchased, the prices, taxes, date, time of the transaction and the name of the merchant. This digital ticket 14 in fact has the same information as the traditionally printed paper receipt.

Step 104 is the timestamp of the digital ticket 14, that is to say the association of the date and time, forming a timestamp 15, corresponding to this ticket 14 and therefore to the transaction.

Step 105 is the selection, from the list 6 of transaction identifiers of the payment device used for the transaction, of one of these identifiers 7 in order to transmit the selected transaction identifier 7. To do this, from the list 6 of transaction identifiers of the payment device, the payment terminal 3 chooses the identifier 7 located at one end of the list 6 corresponding to a selection position. Then, the terminal 3 and/or the payment device 2 implements a step of deleting, in the list 6, this identifier 7 so that the next identifier 7 of the list 6 is in the selection position for a following transaction.

Step 106 is the transmission, from the payment device 2 to the payment terminal 3, of the selected transaction identifier 7. It will only be used for this transaction.

Step 107-A is the generation of an identifier 18 of the digital ticket 14 from the transaction identifier 7. In this variant, the identifier 18 of the digital ticket 14 generated from the transaction identifier 7 is the transaction identifier 7 itself.

In a second variant, step 107-B is a hash of the transaction identifier 7 so that the identifier 18 generated from the transaction identifier 7 is the result of the hash. This variant improves security. In particular, if the transaction identifier 7 was generated in a pseudo-random and non-random manner, the hash makes it possible to limit the risks of this identifier being found by a third party.

Step 108 is the transmission of the digital ticket 14, the identifier 18 of the digital ticket and the timestamp 15 of the digital ticket 14, associated with each other, to the digital ticket database 5. This transmission is carried out by the payment terminal 3. In a variant not illustrated, it is carried out by the merchant's cash register.

System 20 of the differs from that of the in that the payment device 21 further comprises a transaction counter 22.

Mode 200 of the , implemented by the 21 system of the , differs from mode 100 of the in that instead of choosing an identifier at a certain position in the list and deleting it, the selection step has a step of counting, by the transaction counter 22 of the payment device 21, the number of transactions carried out by the payment device 21, the selection of the identifier 7 being carried out according to this count. For example, for the 8th transaction carried out by this payment device 21, the 8th identifier from the list 6 of identifiers is selected.

System 23 of the differs from systems 1 and 20 of the respective figures 1 and 3 in that, instead of a list 6, the payment device 24 comprises a generator 25 of pseudo-random transaction identifiers.

The 300 mode of the , implemented by the 23 system of the , differs from previous modes in that it includes the following steps described below.

Step 301 is the preliminary creation of the generator 25 of pseudo-random transaction identifiers. It is implemented by an entity external to the system, for example by the bank that issued the payment device 24.

Step 302 is the placement, within the payment device 24, of this generator 25.

A parallel step not shown is the placement of an identical generator with the bank, an electronic wallet of the user, the user himself or any entity allowing the user to subsequently generate the same transaction identifiers as the generator 25 placed within the payment device 24. In order for these generators to generate identical numbers, it is necessary that they both be pseudo-random and have identical parameters. Two purely random generators would not generate the same numbers.

Step 303 is, before the transmission of the transaction identifier 7 to the payment terminal 3, the generation, by the generator 25 of pseudo-random transaction identifiers within the payment device 24, of this transaction identifier 7. It is therefore this identifier 7 which is transmitted and used to generate the identifier 18 of the digital ticket, rather than an identifier chosen from a list. At the next transaction another transaction identifier will be generated.

System 26 of the differs from previous systems in that the payment device 27 comprises, in addition to the components mentioned in the various embodiments described, an encryption key 19, called the “public” key. The transmission means 8 are also capable of transmitting this encryption key 19 to the payment terminal 3. A corresponding decryption key, called the private key, is held by an entity external to the system, such as a bank that issued the payment device 27, an electronic wallet of the user or the user himself. Alternatively, in a symmetric encryption system, the same key is used for encrypting and decrypting.

The 400 mode of the , implemented by system 26 of the , differs from the methods described previously in that it includes additional steps described below.

Step 401 is the transmission, from the payment device 27 to the payment terminal 3, of the public encryption key 19.

Step 402 is the encryption of the digital ticket 14 generated by the encryption key. This encryption is carried out by the payment terminal 3 using the key obtained from the payment device 27.

The transmission step 403 to the database 5 is then the transmission not of the digital ticket 14 in clear, but of the encrypted digital ticket 28. It is this encrypted digital ticket 28 which is associated, in the database 5, with the identifier 18 of the ticket 14 and the timestamp 15.

The purpose of this 400 mode is to prevent a third party from generating statistics from digital tickets that they would otherwise obtain in plain text. It also allows for collision management, as discussed below, through decryption.

System 29 of the differs from previous systems in that the automated means of the payment terminal 30 are further capable of:

- receive, from the payment device 2, an identifier 32 (PAN) of the payment device 2;

- generate an identifier 31 of the digital ticket 14 by performing a combination between the identifier 32 of the payment device 2 and the transaction identifier 7, and by performing a hash of a result of the combination. The combination is described below.

The 500 mode of the , implemented by system 29 of the , differs from the methods described previously in that it includes the steps described below.

Step 501 is, before the generation of the identifier 31, the transmission, from the payment device 2 to the payment terminal 30, of the identifier 32 (“PAN”) of the payment device.

Step 502-A is the generation of the identifier 31 of the digital ticket. It is not carried out solely from the transaction identifier 7 as in the method 100. It is carried out by carrying out a combination between the identifier 32 of the payment device and the transaction identifier 7. The combination is the concatenation of the transaction identifier 7 with the identifier 32 of the payment device. Alternatively, the transaction identifier 7 and the identifier 32 of the card are converted into binary numbers, and the combination is the XOR operation between these two binary identifiers. Other types of combination are applicable. It is the result of this combination which is the digital identifier 31 of the ticket 14, and which is associated with the ticket 14 or the encrypted ticket 28 in the database 5.

In a variant, step 502-B differs from step 502-A in that the result of the combination is subject to a hashing operation. It is the hash of the result of the combination which is then the digital identifier 32 of the ticket, and which is associated with the ticket 14 or the encrypted ticket 28 in the database 5.

This mode 500 further improves security compared to the previous modes where only the transaction identifier is necessary to generate the digital ticket identifier. Even in the case where the transaction identifier is generated purely randomly, this mode is advantageous because it allows the creation of the identifiers and the payment device by separate respective entities without trust between them. Indeed, in the case where an entity A creates only transaction identifiers and transfers them to an entity B which creates the payment device and generates the payment device identifier, the combination between the payment device identifier and the transaction identifiers makes it possible to prevent entity A, which would have stored the generated transaction identifiers, from trying to access the digital tickets generated from these transaction identifiers.

The 600 process of the is an updating method, relating to all the modes of implementation of the registration method described above. It comprises the updating, by an ATM and within the payment device 2, of the list of pseudo-random or random transaction identifiers 6 introduced above or of the generator 25 of pseudo-random identifiers introduced above. Thus, the buyer inserts his card 2 into the payment dispenser and obtains the possibility of updating the list if the card operates according to modes 100 or 200 or of updating the generator if the card operates according to method 300. This method 600 can be considered as forming an additional step of a registration method according to one of modes 100 to 500, or as a new mode of implementation 600 of such a registration method.

In another implementation not shown, the list or generator is updated via a user mobile application.

The 700 process of the is a payment method relating to a transaction, comprising, once the payment has been made, the recording of a digital ticket relating 14 to the transaction in accordance with the methods 100 to 600 of the method for recording a digital ticket described above. Thus, the user makes the payment by means of his payment card, and the digital ticket relating to this transaction is recorded in the database in accordance with the methods 100 to 600.

The 800 process of the is a method of retrieving a digital ticket relating to a transaction, the digital ticket having been recorded in accordance with one of the modes of the recording method described above. The user's objective is to retrieve the ticket corresponding to a transaction that he has previously carried out.

Step 801 is obtaining the transaction identifier. This is feasible since the transaction identifier is also held by an entity external to the system, whether it is the bank, a user wallet or the user himself, in accordance with the modes of the registration method described previously.

Step 802 is the generation of a digital ticket identifier from the transaction identifier. This step is the same as that implemented by the payment terminal in the different modes of implementation of the recording method. Thus, if the transaction identifier is the digital identifier, as in step 107-A of mode 100, this is also the case in this recovery method. If hashing is necessary as in step 107-B, the same hashing is performed here, that is to say the transaction identifier is subject to the same hash function, so as to generate the same digital ticket identifier if the transaction identifier is identical. Similarly, if the payment device identifier was combined with the transaction identifier in accordance with step 502-A of mode 500, then this step 802 comprises obtaining the payment device identifier and generating the digital ticket identifier by performing the same combination between the payment device identifier and the transaction identifier. Furthermore, if hashing was performed as in step 502-B, then the same hash function is applied to the result of the combination, so as to generate the same digital ticket identifier.

Step 803 is the retrieval, from the digital ticket database 5, of the digital ticket associated with the generated identifier of the digital ticket. The user thus simply retrieves the digital ticket relating to his transaction, only if he wants it, when he wants it, and without his payment experience having been hindered.

Step 804 is implemented if an encryption of the digital ticket has been carried out in accordance with mode 400 of the registration method. The ticket having been encrypted during registration, and the private key being held by the bank, the digital wallet or the user himself, this recovered digital ticket is decrypted by the decryption private key. The user then recovers the digital ticket in clear. Alternatively, in a symmetric encryption system, the same key is used for encryption and decryption.

The encryption and decryption steps not only prevent statistics from being collected on plaintext tickets, but also allow for the resolution of potential collisions. Indeed, it is theoretically possible for two ticket IDs for two different users to be identical. Since each user has a respective decryption key, a user will only receive the ticket decrypted by their key and will not be able to access the other user's ticket.

The invention is not limited to the embodiments presented and other embodiments will become apparent to those skilled in the art.

Firstly, as already mentioned, it will be clear to those skilled in the art that some of the presented modes can be combined with each other. Thus, the encryption or not of the digital ticket, according to mode 400, is independent of the other steps of the method. Any hashes are also independent of the other steps. The generation of the digital identifier by the combination between the transaction identifier and the payment device identifier differs from the generation of this ticket identifier carried out solely from the transaction identifier. However, these two modes are a way of generating the digital ticket identifier from the transaction identifier, one of the modes not requiring other elements, the other mode requiring in addition the payment device identifier. The presence of a list of identifiers in the payment device does not prevent the presence of an identifier generator, although these two approaches are redundant. Selecting an identifier at a particular place in the list and deleting it does not prevent counting transactions to select the identifier, although again these two approaches to selecting the identifier are redundant.

The possession of the list of transaction identifiers or the generator, the hash functions and the decryption key by an external entity such as a bank or an electronic wallet has been mentioned. It will be clear to those skilled in the art that any other entity capable of allowing the user to recover their digital ticket may have these elements. This may be any platform associated with the system and through which the user can identify themselves and have a private account equipped with the list of identifiers or the generator, possibly the hash functions and the decryption key.

The digital receipt mentioned in the description corresponds to a receipt. However, any receipt "relating to a transaction" is covered by the invention. It can be a payment receipt, which will list the payment information relating to the transaction, but also a receipt relating to information on a purchased product, for example including the product warranty. The user can thus retrieve information on their product, for example the warranty, by accessing this receipt whenever they wish. It can also be information relating to a ticket purchased for an event, since this event is directly associated with the transaction.

List of references
1: Digital ticket registration system
2: payment device
3: payment terminal
4: server
5: database
6: list of transaction identifiers
7: transaction identifier
8: means of communication of the payment device
9: payment device data carrier
10: computer program of the payment device
11: means of communication of the payment terminal
12: payment terminal data support
13: Payment terminal computer program
14: clear digital ticket
15: timestamp of the digital ticket
16: Server data support
17: Server computer program
18: digital ticket identifier
19: encryption key
20: Digital ticket registration system
21: payment device
22: transaction counter
23: Digital ticket registration system
24: payment device
25: pseudo-random transaction identifier generator
26: Digital ticket registration system
27: payment device
28: encrypted digital ticket
29: digital ticket registration system
30: payment terminal
31: digital ticket identifier
32: payment device identifier
100, 200, 300, 400, 500: process for registering a digital ticket
600: method for updating transaction identifiers or an identifier generator
700: payment method
800: process for recovering a digital ticket

Claims (15)

Method (100; 200; 300; 400; 500; 600) for recording a digital ticket relating to a transaction, implemented by computer, characterized in that it comprises the following steps:
- generation (103) of a digital ticket (14; 28) relating to a transaction;
- timestamp (104) of the digital ticket (14; 28);
- transmission (106), from a payment device (2; 21; 24; 27) used for the transaction to a payment terminal (3; 30) used for the transaction, of a transaction identifier (7);
- generation (107) of an identifier of the digital ticket (18; 31) from the transaction identifier (7);
- transmission (108) of the digital ticket (14; 28), of the identifier (18; 31) of the digital ticket and of the timestamp (15) of the digital ticket, associated with each other, to a database (5) of digital tickets. Method (100; 200; 300; 400; 600) according to the preceding claim, in which:
- the identifier (18) of the generated digital ticket (107-A) from the transaction identifier is the transaction identifier (7), or
- the method comprises a step of hashing (107-B) the transaction identifier (7) so that the digital identifier (18) generated from the transaction identifier (7) is the result of the hashing. The method (500) of claim 1, comprising the following steps:
- before the generation of the digital identifier, transmission (501), from the payment device (2) to the payment terminal (30), of an identifier (32) of the payment device;
- the generation (502) of the identifier (31) of the digital ticket from the transaction identifier (7) is carried out by carrying out a combination between the identifier (32) of the payment device and the transaction identifier (7), preferably also by carrying out a hash (502-B) of a result of the combination. A method (400) according to any preceding claim, comprising the following steps:
- transmission (401), from the payment device (27) to the payment terminal (3), of an encryption key (19);
- encryption of the digital ticket (14) generated by the encryption key (19);
and wherein the step of transmitting (403) the digital ticket to the database is the transmission of the encrypted digital ticket (28). Method (100; 200; 400; 500; 600) according to any one of the preceding claims, comprising, before the transmission of the transaction identifier to the payment terminal, a step of selecting (105), from a list of transaction identifiers (6) of the payment device, one of these identifiers (7) with a view to transmitting the selected transaction identifier. Method according to the preceding claim (100; 200; 400; 500; 600), comprising:
- a counting step (200), by a transaction counter (22) of the payment device (21), of the number of transactions carried out by the payment device, the selection of the identifier (7) being carried out as a function of this counting; or
- the selection (105), from the list of transaction identifiers (6) of the payment device, of the identifier (7) located at one end of the list corresponding to a selection position, then the deletion, in the list, of this identifier so that the next identifier in the list is in the selection position for a following transaction. Method (100; 200; 400; 500; 600) according to claim 5 or 6, comprising, prior to the transaction, the following steps:
- generation (101) of a list (6) of pseudo-random or random transaction identifiers;
- recording (102), within the payment device (2), of this list (6) of transaction identifiers. Method (300) according to any one of claims 1 to 4, comprising, before the transmission of the transaction identifier to the payment terminal, a step of generation (301), by a generator (25) of pseudo-random identifiers of the payment device (24), of this transaction identifier (7). Payment method (700) relating to a transaction, comprising, once the payment has been made, recording a digital ticket relating to the transaction in accordance with the method (100; 200; 300; 400; 500; 600) according to any one of the preceding claims. A method of retrieving (800) a digital ticket relating to a transaction, the digital ticket (14; 28) having been recorded in accordance with any one of claims 1 to 8, comprising the following steps:
- obtaining (801) the transaction identifier;
- generation (802) of a digital ticket identifier from the transaction identifier;
- retrieving (803), in the digital ticket database (5), the digital ticket (14; 28) associated with the identifier (18; 31) generated from the digital ticket. Computer program (10; 13; 17) comprising instructions which, when the program is executed by a computer, cause the latter to implement the steps of the registration method (100; 200; 300; 400; 500; 600) according to any one of claims 1 to 8, of the payment method (700) according to claim 9 or of the recovery method (800) according to claim 10. A computer-readable recording medium (9; 12; 16) comprising instructions which, when executed by a computer, cause the computer to implement the steps of the recording method (100; 200; 300; 400; 500; 600) according to any one of claims 1 to 8, of the payment method (700) according to claim 9 or of the recovery method (800) according to claim 10. Database (5) of digital tickets, characterized in that it comprises at least one digital ticket (14; 28) recorded in accordance with the method according to one of claims 1 to 8 (100; 200; 300; 400; 500; 600), the ticket being associated, in the database, with the identifier (18; 31) of the generated ticket and with the timestamp (15) of the ticket. Payment device (2; 21; 24; 27), characterized in that it comprises:
- a list (6) of transaction identifiers or a generator (25) of pseudo-random transaction identifiers;
- means of transmission (8), to a payment terminal (3; 30), of a transaction identifier from the list or of a pseudo-random identifier generated by the generator. Payment terminal (3; 30), characterized in that it comprises automated means capable of:
- receive, from a payment device (2; 21; 24; 27), a transaction identifier (7),
- generating an identifier of a digital ticket (18; 31) relating to the transaction from the transaction identifier (7);
- transmitting the digital ticket (18; 31), associated with the identifier of the generated digital ticket and the timestamp (15) of the digital ticket, to a database (5) of digital tickets.