Brevet FR3156559A1 — publié le 20250613

L’invention est un procédé d’enregistrement d’un ticket numérique relatif à une transaction, mis en œuvre par ordinateur, caractérisé en ce qu’il comprend les étapes suivantes : - génération d’un ticket numérique (14) relatif à une transaction ; - horodatage du ticket numérique (14) ; - transmission, depuis un dispositif de paiement (2) utilisé pour la transaction vers un terminal de paiement (3) utilisé pour la transaction, d’un identifiant de transaction (7) ; - génération d’un identifiant du ticket numérique (18) à partir de l’identifiant de transaction (7) ; - transmission du ticket numérique (14), de l’identifiant (18) du ticket numérique et de l’horodatage (15) du ticket numérique, associés entre eux, vers une base de données (5) de tickets numériques. Figure pour l’abrégé : figure 1 Procédé d’enregistrement d’un ticket numérique relatif à une transaction L’invention concerne la gestion des tickets numériques. Elle concerne en particulier la dématérialisation des « tickets de caisse ». Quand une transaction fait l’objet d’un règlement par un dispositif de paiement auprès d’un terminal de paiement, un ticket de caisse et un reçu de paiement, tous deux généralisés sous l’appellation « tickets » dans la suite, sont habituellement imprimés et fournis à l’acheteur afin qu’il dispose des informations relatives à la transaction, notamment des informations de paiement. Cependant, les tickets papiers de ce type ont vocation à disparaître, ce qui permet de supprimer les besoins en papier et d’économiser les frais d’achat et d’entretien des composants d’impression de ces tickets. Pour continuer à fournir les informations de transaction à l’acheteur, une alternative aux tickets papiers est la génération de tickets numériques. Il convient donc de disposer d’un moyen de transmettre un ticket numérique, relatif à une transaction, à un acheteur venant de réaliser une transaction. On connaît déjà dans l’état de la technique une solution consistant à envoyer le ticket numérique généré par courriel ou sms à l’utilisateur. Cependant, cela nécessite que l’utilisateur fournisse son adresse courriel ou son numéro de téléphone au commerçant. C’est un processus contraignant pour l’utilisateur, qui peut comporter des erreurs, et qui présente en outre des risques du point de vue de la confidentialité de ses données, lesquelles peuvent être vues ou entendues ou, en ce qui concerne les adresses courriels, faire l’objet d’attaques dites de « spear-fishing » (ou hameçonnage ciblé, en français). C’est également un processus particulièrement chronophage en cas de flux tendu d’acheteurs auprès des caisses de paiements. On connait également déjà dans la technique une solution consistant à rendre accessible le ticket directement au terminal mobile de l’utilisateur via une communication par champ proche ou par QR-code. Ainsi, on connaît notamment d'après les documents EP3382628 et KR102444679, un procédé dans lequel, après transaction, un terminal de paiement utilisé pour cette transaction transmet, par communication en champ proche, vers un terminal mobile utilisé pour la transaction, une adresse web permettant au terminal mobile d’accéder au ticket numérique relatif à la transaction, voire le ticket lui-même dans le cas du document EP3382628. Cependant, cela oblige l’acheteur à effectuer son paiement au moyen d’un terminal mobile et à disposer d’une application mobile appropriée. Ce processus n’est donc pas adapté à tous les consommateurs, qui ne disposent pas tous d’un smartphone ou, pour ceux qui disposent d’un smartphone, qui ne souhaitent pas se déplacer en permanence avec lui, ne souhaitent pas régler une transaction avec lui ou ne souhaitent pas multiplier les applications mobiles. Ce processus est également contraignant puisqu’il oblige à l’acheteur à sortir et manipuler son terminal mobile lors du paiement. En outre, ce processus consomme l’énergie du terminal mobile ainsi que sa mémoire. Enfin, de manière générale, la communication en champ proche (« Near- field communication », ou NFC, en anglais) est, de même que l’usage de QR-code, un processus qui nécessite l’usage d’applications mobiles qui vont nécessairement être mises à jour régulièrement pour être adaptées à toutes les plateformes et à toutes les versions de ces plateformes, forçant les utilisateurs à renouveler leurs terminaux mobiles sauf à perdre l’accès à leurs tickets numériques. L'invention a notamment pour but de fournir une solution permettant à un utilisateur de disposer d’un accès à un ticket numérique relatif à une transaction sans que l’expérience de paiement vécue par l’utilisateur ne diffère de celle associée aux tickets papiers. À cet effet, l’invention a pour objet un procédé d’enregistrement d’un ticket numérique relatif à une transaction, mis en œuvre par ordinateur, comprenant les étapes suivantes : - génération d’un ticket numérique relatif à une transaction ; - horodatage du ticket numérique ; - transmission, depuis un dispositif de paiement utilisé pour la transaction vers un terminal de paiement utilisé pour la transaction, d’un identifiant de transaction ; - génération d’un identifiant du ticket numérique à partir de l’identifiant de transaction ; - transmission du ticket numérique, de l’identifiant du ticket numérique et de l’horodatage du ticket numérique, associés entre eux, vers une base de données de tickets numériques. Ainsi, il n’est pas nécessaire de disposer d’un terminal mobile ni de fournir des coordonnées pour enregistrer le ticket numérique relatif à la transaction. Le dispositif de paiement fournit directement, lors du paiement, les informations au terminal permettant de générer un identifiant du ticket numérique, en particulier l’identifiant de transaction, cet identifiant de transaction étant propre à la transaction. Cet identifiant enregistré au sein du dispositif de paiement est connu de la banque de l’utilisateur, de son portefeuille numérique ou de l’utilisateur lui-même, de sorte que l’utilisateur peut ensuite accéder au ticket numérique dans la base de données à partir de cet identifiant. En particulier, le dispositif de paiement dispose soit d’une liste d’identifiants aléatoires ou pseudo-aléatoires de transaction préenregistrés et d’un compteur, permettant de choisir un identifiant unique de la liste pour chaque transaction, soit d’un générateur d’identifiants pseudo-aléatoires de transaction permettant de générer un identifiant unique à chaque transaction. Le processus de paiement est inchangé vis-à-vis des processus associés aux tickets papiers. L’expérience utilisateur est même moins contraignante puisqu’aucun ticket papier n’est à attendre au moment du paiement, et l’utilisateur décide par lui-même s’il veut récupérer ou non son ticket numérique dans la base de données, dans un moment ultérieur de son choix. Suivent d’autres caractéristiques optionnelles prises seules ou en combinaison. Avantageusement, l’identifiant du ticket numérique généré à partir de l’identifiant de transaction est l’identifiant de transaction, ou le procédé comprend une étape de hachage de l’identifiant de transaction de sorte que l’identifiant numérique généré à partir de l’identifiant de transaction est le résultat du hachage. Ainsi, l’identifiant de transaction transmis par le dispositif de paiement est directement utilisé pour générer l’identifiant du ticket numérique, sans que d’autres informations soient nécessaires, ou il est l’objet d’un hachage. L’identifiant est avantageusement le résultat d’un générateur pseudo-aléatoire d’identifiants. Dans le cas où l’identifiant est le fruit d’un générateur pseudo-aléatoire d’identifiants, le hachage permet d’éviter que les paramètres du générateur soient retrouvés par un tiers. Alternativement, le procédé comprend les étapes suivantes : - avant la génération de l’identifiant numérique, transmission, du dispositif de paiement vers le terminal de paiement, d’un identifiant du dispositif de paiement ; - la génération de l’identifiant du ticket numérique à partir de l’identifiant de transaction est effectuée en réalisant une combinaison entre l’identifiant du dispositif de paiement et l’identifiant de transaction, de préférence également en réalisant un hachage d’un résultat de la combinaison. Ainsi, dans ce cas l’identifiant de transaction n’est pas directement transformé en identifiant du ticket numérique. En effet, le dispositif de paiement transmet au terminal de paiement, en plus de cet identifiant de transaction qui est propre à une transaction donnée, un identifiant du dispositif du paiement qui reste le même à chaque transaction puisqu’il caractérise le dispositif de paiement. Il peut s’agir par exemple de l’identifiant PAN (pour « Primary Account Number ») dans le cas où le dispositif de paiement est une carte bancaire. L’identifiant du dispositif est, comme l’identifiant de transaction, issu du dispositif de paiement possédé par l’utilisateur et également connu de la banque de l’utilisateur ayant émis ce dispositif de paiement, d’un portefeuille électronique de l’utilisateur voire de l’utilisateur lui-même, de sorte que l’utilisateur peut à tout moment générer l’identifiant du ticket numérique pour retrouver, dans la base de données de tickets numériques, le ticket numérique relatif à sa transaction. Le fait de combiner cet identifiant du dispositif de paiement à l’identifiant de transaction rend encore plus sûr la confidentialité des tickets numériques. En particulier, dans le cas où les identifiants de transaction sont générés de façon pseudo-aléatoire, leur combinaison avec l’identifiant du dispositif de paiement empêche un tiers de retrouver l’identifiant du ticket numérique uniquement à partir des paramètres du générateur. En outre, dans le cas où, à l’initialisation du dispositif de paiement, une entité spécifique, pour laquelle aucune confiance n’est accordée, est responsable de générer les identifiants de transaction, le fait de combiner ces derniers à l’identifiant du dispositif de paiement permet d’éviter que cette entité, qui ignore l’identifiant du dispositif de paiement, puisse retrouver les identifiants des tickets numériques correspondants aux identifiants qu’elle a générés. De préférence, le procédé comprend les étapes suivantes : - transmission, du dispositif de paiement vers le terminal de paiement, d’une clé de chiffrement ; - chiffrement du ticket numérique généré par la clé de chiffrement; et dans lequel l’étape de transmission du ticket numérique vers la base de données est la transmission du ticket numérique chiffré. Ainsi, le contenu du ticket numérique est chiffré. Cela permet d’éviter qu’une entité tierce tente d’obtenir des informations, par exemple de générer des statistiques, en réalisant des requêtes aléatoires sur la base de données de tickets numériques. La clé de chiffrement est donc installée dans le dispositif de paiement à son initialisation, tandis que la clé de déchiffrement correspondante est connue de la banque de l’utilisateur, de son portefeuille numérique ou de lui-même, ce qui lui permet de déchiffrer le contenu du ticket numérique lorsque l’utilisateur souhaite y accéder. Cette paire de clés peut être une paire de clés asymétriques. Dans un tel cas, on considère que la clé de chiffrement installée dans le dispositif est la clé publique, tandis que la clé de déchiffrement, privée, est gardée confidentielle par la banque, le portefeuille numérique ou l’utilisateur lui-même. Alternativement, une seule et même clé peut être utilisée pour le chiffrement et le déchiffrement. Avantageusement, le procédé comprend, avant la transmission de l’identifiant de transaction vers le terminal de paiement, une étape de sélection, parmi une liste d’identifiants de transaction du dispositif de paiement, de l’un de ces identifiants en vue de transmettre l’identifiant de transaction sélectionné. Ainsi, les identifiants de transaction sont préenregistrés dans le dispositif de paiement sous la forme d’une liste. À chaque transaction est utilisé un identifiant de cette liste. Avantageusement, le procédé comprend : - une étape de comptage, par un compteur de transactions du dispositif de paiement, du nombre de transactions effectuées par le dispositif de paiement, la sélection de l’identifiant étant réalisée en fonction de ce comptage ; ou - la sélection, parmi la liste d’identifiants de transaction du dispositif de paiement, de l’identifiant situé à une extrémité de la liste correspondant à une position de sélection, puis la suppression, dans la liste, de cet identifiant de manière à ce que l’identifiant suivant de la liste se retrouve en position de sélection pour une transaction suivante. Ainsi, pour éviter de sélectionner deux fois le même identifiant pour deux transactions distinctes, deux possibilités sont offertes : dans le cas du comptage, le compteur du dispositif de paiement incrémente son comptage pour que soit sélectionné l’identifiant correspondant au comptage. Alternativement, l’identifiant de transaction sélectionné est celui qui se trouve en extrémité de liste, au sein de la liste d’identifiants de transaction du dispositif de paiement. Cet identifiant est supprimé après la transaction, de façon à sélectionner l’identifiant suivant de la liste à la prochaine transaction. Cela permet de se passer de compteur. Avantageusement, le procédé comprend, au préalable de la transaction, les étapes suivantes : - génération d’une liste d’identifiants pseudo-aléatoires ou aléatoires de transaction ; - enregistrement, au sein du dispositif de paiement, de cette liste d’identifiants de transaction. Ainsi, ces étapes ont lieu à l’initialisation du dispositif de paiement, par exemple à la fabrication de la carte de paiement lorsque le dispositif de paiement est une carte de paiement. Alternativement, le procédé comprend, avant la transmission de l’identifiant de transaction vers le terminal de paiement, une étape de génération, par un générateur d’identifiants pseudo-aléatoires de transactions au sein du dispositif de paiement, de cet identifiant de transaction. Ainsi, une liste d’identifiants de transaction n’est, dans ce cas, pas enregistrée au sein du dispositif de paiement. À la place, c’est un générateur d’identifiants qui est intégré au dispositif, et génère un identifiant de transaction à chaque de transaction. Ce générateur génère des identifiants de façon pseudo-aléatoire. La banque, le portefeuille numérique ou l’utilisateur disposent du même générateur, de façon à générer les mêmes identifiants, afin de pouvoir retrouver les tickets numériques dans la base de données. Avantageusement, le procédé comprend, au préalable de la transaction, les étapes suivantes : - création du générateur d’identifiants pseudo-aléatoires de transactions ; - placement, au sein du dispositif de paiement, de ce générateur. De préférence, le procédé comprend la mise à jour, par un distributeur automatique de billets et au sein du dispositif de paiement, de la liste d’identifiants aléatoires ou pseudo-aléatoires de transactions introduite plus haut ou du générateur d’identifiants pseudo-aléatoires introduit plus haut. Ainsi, l’utilisateur peut « recharger » sa liste d’identifiants de transaction auprès d’un distributeur de billets. L’invention a également pour objet un procédé de paiement relatif à une transaction, comprenant, une fois le paiement réalisé, l’enregistrement d’un ticket numérique relatif à la transaction conformément au procédé décrit précédemment. L’invention a également pour objet un procédé de récupération d’un ticket numérique relatif à une transaction, le ticket numérique ayant été enregistré conformément à l’une quelconque des revendications précédentes, comprenant les étapes suivantes : - obtention de l’identifiant de la transaction ; - génération d’un identifiant du ticket numérique à partir de l’identifiant de transaction ; - récupération, dans la base de données de tickets numériques, du ticket numérique associé à l’identifiant généré du ticket numérique. Avantageusement, dans le procédé de récupération, l’identifiant du ticket numérique est l’identifiant de transaction, ou le procédé comprend une étape de hachage de l’identifiant de transaction de sorte que l’identifiant numérique est le résultat du hachage. De préférence, le procédé de récupération comprend les étapes suivantes : - avant la génération de l’identifiant numérique, obtention de l’identifiant du dispositif de paiement, - génération de l’identifiant du ticket numérique en réalisant une combinaison entre l’identifiant du dispositif de paiement et l’identifiant de transaction, de préférence également en réalisant un hachage d’un résultat de la combinaison. Avantageusement, le ticket ayant été chiffré lors de l’enregistrement conformément au procédé décrit plus haut, ce ticket numérique récupéré est déchiffré par une clé de déchiffrement. L’invention a également pour objet un programme d'ordinateur comprenant des instructions qui, lorsque le programme est exécuté par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes du procédé d’enregistrement décrit plus haut, du procédé de paiement décrit plus haut ou du procédé de récupération décrit plus haut. L’invention a également pour objet un support d'enregistrement lisible par ordinateur comprenant des instructions qui, lorsqu'elles sont exécutées par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes du procédé d’enregistrement décrit plus haut, du procédé de paiement décrit plus haut ou du procédé de récupération décrit plus haut. L’invention a également pour objet une base de données de tickets numériques, comprenant au moins un ticket numérique enregistré conformément au procédé décrit plus haut, le ticket étant associé, dans la base de données, à l’identifiant du ticket généré et à l’horodatage du ticket. L’invention a également pour objet un dispositif de paiement, comprenant: - un identifiant du dispositif de paiement ; - une liste d’identifiants de transactions ou un générateur d’identifiants pseudo-aléatoires de transactions ; - des moyens de transmission, à un terminal de paiement, de l’identifiant du dispositif de paiement ; - des moyens de transmission, à un terminal de paiement, d’un identifiant de transaction de la liste ou d’un identifiant pseudo-aléatoire généré par le générateur. De préférence, le dispositif comprend en outre une clé de chiffrement, les moyens de transmissions étant aptes à transmettre également cette clé. Avantageusement, le dispositif comprend en outre un compteur de transactions. L’invention a également pour objet un terminal de paiement, comprenant des moyens automatisés aptes à : - recevoir, d’un dispositif de paiement, un identifiant de transaction, - générer un identifiant d’un ticket numérique relatif à la transaction à partir de l’identifiant de transaction ; - transmettre le ticket numérique, associé à l’identifiant du ticket numérique généré et à l’horodatage du ticket numérique, vers une base de données de tickets numériques. Avantageusement, les moyens automatisés sont aptes en outre à : - recevoir, d’un dispositif de paiement, un identifiant du dispositif de paiement ; - générer un identifiant du ticket numérique en réalisant une combinaison entre l’identifiant du dispositif de paiement et l’identifiant de transaction, de préférence également en réalisant un hachage d’un résultat de la combinaison. Brève description des figures L'invention sera mieux comprise à la lecture de la description qui va suivre donnée uniquement à titre d'exemple et faite en se référant aux dessins annexés dans lesquels : FIG. 1 est un schéma d’un système d’enregistrement d’un ticket numérique relatif à une transaction selon un premier mode de réalisation ; FIG. 2 est un logigramme d’un premier mode de mise en œuvre d’un procédé d’enregistrement d’un ticket relatif à une transaction par le système de la FIG. 1 ; FIG. 3 est un schéma d’un système d’enregistrement d’un ticket numérique relatif à une transaction selon un deuxième mode de réalisation ; FIG. 4 est un logigramme d’un deuxième mode de mise en œuvre du procédé par le système de la FIG. 3 ; FIG. 5 est un schéma d’un système d’enregistrement d’un ticket numérique relatif à une transaction selon un troisième mode de réalisation ; FIG. 6 est un logigramme d’un troisième mode de mise en œuvre du procédé par le système de la FIG. 5 ; FIG. 7 est un schéma d’un système d’enregistrement d’un ticket numérique relatif à une transaction selon un quatrième mode de réalisation ; FIG. 8 est un logigramme d’un quatrième mode de mise en œuvre du procédé par le système de la FIG. 7 ; FIG. 9 est un schéma d’un système d’enregistrement d’un ticket numérique relatif à une transaction selon un cinquième mode de réalisation ; FIG. 10 est un logigramme d’un cinquième mode de mise en œuvre du procédé par le système de la FIG. 9 ; FIG. 11 est un logigramme d’un procédé de mise à jour ; FIG. 12 est un logigramme d’un procédé de paiement ; FIG. 13 est un logigramme d’un procédé de récupération de ticket numérique. Description détaillée Le système 1 de la FIG. 1 est un système d’enregistrement d’un ticket numérique relatif à une transaction. Il comprend un dispositif de paiement 2 prenant la forme d’une carte à puce de paiement 2. Ce système 1 comprend également un terminal de paiement 3. Ce système 1 comprend également un serveur 4 et une base de données 5 de tickets numériques. On désigne par « dispositif de paiement » tout dispositif apte à réaliser un paiement côté acheteur, tel qu’un terminal mobile ou un dispositif connecté quelconque, dans la mesure où ce dispositif de paiement est configuré pour réaliser un paiement en combinaison avec un terminal de paiement. Le dispositif de paiement 2 comprend en son sein un identifiant 32 (pour « Primary Account Number »). Il comprend également des moyens de réalisation d’un paiement selon des protocoles connus de l’homme du métier et qui ne seront pas décrits en détail. Le dispositif de paiement 2 comprend en outre une liste 6 d’identifiants de transactions. Il s’agit d’identifiants d’un format quelconque pour l’homme du métier, par exemple un nombre aléatoire rendu lisible sous format hexadécimal, ou sous format « base64 ». Ces identifiants sont générés au préalable de façon pseudo-aléatoire ou aléatoire. Il est avantageux que ces identifiants soient générés de façon purement aléatoire. En effet, dans ce cas, il est impossible pour un tiers malveillant, à partir d’une partie d’une liste de ces identifiants, de retrouver certaines caractéristiques communes entre ces identifiants permettant de générer les autres identifiants de la liste. Cependant, il est plus simple et généralement suffisant de générer des identifiants de façon pseudo-aléatoire, c’est-à-dire des identifiants suffisamment indépendants les uns les autres, générés dans une séquence d’identifiants présentant certaines propriétés du hasard. Le dispositif 2 comprend des moyens de transmission 8, au terminal de paiement 3, d’un identifiant de transaction 7 de la liste 6. La carte 2 comprend également un support d'enregistrement 9 lisible par ordinateur, en particulier par un microprocesseur, comprenant des instructions qui, lorsqu'elles sont exécutées par un tel microprocesseur, conduisent celui-ci à mettre tout ou partie des étapes des différents modes 100, 200, 300, 400, 500 ou 600 du procédé d’enregistrement décrits plus bas, du procédé de paiement 700 décrit plus bas ou du procédé de récupération 800 décrit plus bas. Pour ce faire, ce support 9 comprend un programme d’ordinateur 10. Le programme 10 comprend des instructions qui, lorsque le programme 10 est exécuté par un ordinateur, en particulier par un microprocesseur, conduisent celui-ci à mettre en œuvre tout ou partie des étapes des différents modes 100, 200, 300, 400, 500 ou 600 du procédé d’enregistrement décrits plus bas, du procédé de paiement 700 décrit plus bas ou du procédé de récupération 800 décrit plus bas. On désigne par « terminal de paiement » tout dispositif apte à participer à un paiement côté vendeur. Le terminal de paiement 3 comprend des moyens de communication 11, avec le dispositif de paiement 2, connus de l’homme du métier et qui ne seront donc pas décrits en détail. Le terminal 3 comprend également des moyens de réalisation d’un paiement selon des protocoles connus de l’homme du métier et qui ne seront pas décrits en détail. Il comprend en également un support d'enregistrement 12 lisible par ordinateur, en particulier par un microprocesseur, comprenant des instructions qui, lorsqu'elles sont exécutées par un tel microprocesseur, conduisent celui-ci à mettre en œuvre tout ou partie des étapes des différents modes 100, 200, 300, 400, 500 ou 600 du procédé d’enregistrement décrits plus bas, du procédé de paiement 700 décrit plus bas ou du procédé de récupération 800 décrit plus bas. Pour ce faire, ce support 12 comprend un programme d’ordinateur 13. Le programme 13 comprend des instructions qui, lorsque le programme 13 est exécuté par un ordinateur, en particulier par un microprocesseur, conduisent celui-ci à mettre en œuvre tout ou partie des étapes des différents modes 100, 200, 300, 400, 500 ou 600 du procédé d’enregistrement décrits plus bas, du procédé de paiement 700 décrit plus bas ou du procédé de récupération 800 décrit plus bas. En particulier, il résulte de la combinaison des moyens conventionnels du terminal de paiement 3 et des moyens du terminal 3 spécifiquement configurés pour mettre en œuvre les procédés décrits plus bas que le terminal 3 comprend en particulier des moyens automatisés aptes à : - recevoir, du dispositif de paiement 2, un identifiant de transaction 7, - générer un identifiant 18 d’un ticket numérique 14 à partir de l’identifiant de transaction 7 ; - transmettre le ticket numérique 14, associé à l’identifiant 18 du ticket numérique généré et à l’horodatage 15 du ticket numérique, vers la base de données 5 de tickets numériques. La base de données 5 comprend, sous forme de tables de données, des tickets numériques relatifs à des transactions, sous forme chiffrée ou sous forme claire. Chacun de ces tickets est associé à un identifiant 18 du ticket numérique qui est généré conformément aux modes 100, 200, 300, 400, 500 ou 600 du procédé d’enregistrement décrits plus bas. Chacun de ces tickets est également associé à un horodatage 15 permettant de déterminer à quel moment a été généré le ticket. Le serveur 4 permet d’accéder, lire et modifier le contenu de la base de données 5 de tickets numériques. Ce serveur 4 comprend donc des moyens à cet effet conventionnels pour l’homme du métier. Il comprend des moyens de communication avec le terminal de paiement 3 Il comprend également un support d'enregistrement 16 lisible par ordinateur, en particulier par un microprocesseur, comprenant des instructions qui, lorsqu'elles sont exécutées par un tel microprocesseur, conduisent celui-ci à mettre tout ou partie des étapes des modes 100, 200, 300, 400, 500 ou 600 du procédé d’enregistrement décrits plus bas, du procédé de paiement 700 décrit plus bas ou du procédé de récupération 800 décrit plus bas. Pour ce faire, ce support 16 comprend un programme d’ordinateur 17. Le programme 17 comprend des instructions qui, lorsque le programme 17 est exécuté par un ordinateur, en particulier par un microprocesseur, conduisent celui-ci à mettre en œuvre tout ou partie des étapes des modes 100, 200, 300, 400, 500 ou 600 du procédé d’enregistrement décrits plus bas, du procédé de paiement 700 décrit plus bas ou du procédé de récupération 800 décrit plus bas. Les trois programmes d’ordinateurs 10, 13 et 17 évoqués permettent donc au dispositif de paiement 2, au terminal de paiement 3 et à la base de données 5 (via son serveur 4) de communiquer entre eux pour mettre en œuvre les procédés décrits plus bas. On va maintenant décrire des modes de mise en œuvre 100 à 600 d’un procédé d’enregistrement d’un ticket numérique relatif à une transaction, mis en œuvre par ordinateur, en particulier mis en œuvre par les moyens automatisés du dispositif de paiement 2, du terminal de paiement 3 et du serveur 4. Il apparaîtra clairement à l’homme du métier quels modes peuvent être combinés ensemble. On va d’abord décrire le mode 100 mis en œuvre par le système 1 de la FIG. 1 . L’étape 101, mise en œuvre au préalable d’une transaction, est la génération d’une liste 6 d’identifiants pseudo-aléatoires ou aléatoires de transaction. Elle est réalisée par une entité extérieure au système, par exemple par la banque ayant émis la carte de paiement 2. Une liste d’identifiants « aléatoires » est préférée à une liste d’identifiants « pseudo-aléatoires » pour des raisons de sécurité évoquées, mais la génération d’une liste pseudo-aléatoire est généralement plus simple. L’étape 102 est l’enregistrement, au sein du dispositif de paiement 2, de cette liste 6 d’identifiants de transaction. Une étape mise en œuvre en parallèle est l’enregistrement de cette liste 6 par une entité externe au système, telle que la banque ayant émis le dispositif de paiement, un portefeuille électronique de l’utilisateur ou l’utilisateur lui-même, au sein d’une base de données dédiée, en vue de la récupération du ticket numérique par la suite. Pour ce faire, si les identifiants ont été générés de façon purement aléatoire, ils sont transmis à l’entité externe, cette dernière ne pouvant les trouver par elle-même. Si en revanche ils ont été générés de façon pseudo-aléatoire par un générateur pseudo-aléatoire, le même générateur peut être utilisé par l’entité externe, selon des paramètres connus, pour générer les mêmes identifiants. Les étapes suivantes ont lieu lors de la transaction entre un acheteur, disposant de la carte de paiement 2, et un marchand, disposant du terminal de paiement 3. L’acheteur réalise le paiement grâce à l’interaction entre sa carte 2 et le terminal 3. L’étape 103 est la génération d’un ticket numérique 14 relatif à la transaction. Ce ticket 14 est généré par le terminal de paiement utilisé 4 pour la transaction, éventuellement en collaboration avec une caisse de paiement du marchand, selon des protocoles qui ne sont pas l’objet de l’invention. Le ticket numérique 14 est un ticket de caisse qui reprend les informations relatives à la transaction telles que les articles achetés, les prix, taxes, date, heure de la transaction et la dénomination du commerçant. Ce ticket numérique 14 a en effet les mêmes informations que le ticket de caisse papier traditionnellement imprimé. L’étape 104 est l’horodatage du ticket numérique 14, c’est-à-dire l’association de la date et de l’heure, formant un horodatage 15, correspondantes à ce ticket 14 et donc à la transaction. L’étape 105 est la sélection, parmi la liste 6 d’identifiants de transaction du dispositif de paiement utilisé pour la transaction, de l’un de ces identifiants 7 en vue de transmettre l’identifiant de transaction 7 sélectionné. Pour ce faire, parmi la liste 6 d’identifiants de transaction du dispositif de paiement, le terminal de paiement 3 choisit l’identifiant 7 situé à une extrémité de la liste 6 correspondant à une position de sélection. Ensuite, le terminal 3 et/ou le dispositif de paiement 2 met (-tent) en œuvre une étape de suppression, dans la liste 6, de cet identifiant 7 de manière à ce que l’identifiant suivant 7 de la liste 6 se retrouve en position de sélection pour une transaction suivante. L’étape 106 est la transmission, depuis le dispositif de paiement 2 vers le terminal de paiement 3, de l’identifiant de transaction 7 sélectionné. Il ne sera utilisé que pour cette transaction. L’étape 107-A est la génération d’un identifiant 18 du ticket numérique 14 à partir de l’identifiant de transaction 7. Dans cette variante, l’identifiant 18 du ticket numérique 14 généré à partir de l’identifiant de transaction 7 est l’identifiant de transaction 7 lui-même. Dans une deuxième variante, l’étape 107-B est un hachage de l’identifiant de transaction 7 de sorte que l’identifiant 18 généré à partir de l’identifiant de transaction 7 est le résultat du hachage. Cette variante améliore la sécurité. En particulier, si l’identifiant de transaction 7 a été générée de façon pseudo-aléatoire et non aléatoire, le hachage permet de limiter les risques que cet identifiant soit retrouvé par un tiers. L’étape 108 est la transmission du ticket numérique 14, de l’identifiant 18 du ticket numérique et de l’horodatage 15 du ticket numérique 14, associés entre eux, vers la base de données 5 de tickets numériques. Cette transmission est réalisée par le terminal de paiement 3. Dans une variante non illustrée, elle est réalisée par la caisse du commerçant. Le système 20 de la FIG. 3 diffère de celui de la FIG. 1 en ce que le dispositif de paiement 21 comprend en outre un compteur de transactions 22. Le mode 200 de la FIG. 4 , mis en œuvre par le système 21 de la FIG. 3 , diffère du mode 100 de la FIG. 2 en ce qu’au lieu de choisir un identifiant à une certaine position de la liste et de le supprimer, l’étape de sélection présente une étape de comptage, par le compteur de transactions 22 du dispositif de paiement 21, du nombre de transactions effectuées par le dispositif de paiement 21, la sélection de l’identifiant 7 étant réalisée en fonction de ce comptage. À titre d’exemple, pour la 8eme transaction réalisée par ce dispositif de paiement 21, le 8eme identifiant de la liste 6 des identifiants est sélectionné. Le système 23 de la FIG. 5 diffère des systèmes 1 et 20 des figures respectives 1 et 3 en ce que, à la place d’une liste 6, le dispositif de paiement 24 comprend un générateur 25 d’identifiants pseudo-aléatoires de transactions. Le mode 300 de la FIG. 6 , mis en œuvre par le système 23 de la FIG. 5 , diffère des modes précédents en ce qu’il comprend les étapes suivantes décrites ci-après. L’étape 301 est la création préalable du générateur 25 d’identifiants pseudo-aléatoires de transactions. Elle est mise en œuvre par une entité externe au système, par exemple par la banque ayant émis le dispositif de paiement 24. L’étape 302 est le placement, au sein du dispositif de paiement 24, de ce générateur 25. Une étape parallèle non illustrée est le placement d’un générateur identique auprès de la banque, d’un portefeuille électronique de l’utilisateur, de l’utilisateur lui-même ou de toute entité permettant à l’utilisateur de générer ultérieurement les mêmes identifiants de transaction que le générateur 25 placé au sein du dispositif de paiement 24. Afin que ces générateurs génèrent des nombres identiques, il est nécessaire qu’ils soient tous deux pseudo-aléatoires et aux paramètres identiques. Deux générateurs purement aléatoires ne génèreraient pas les mêmes nombres. L’étape 303 est, avant la transmission de l’identifiant de transaction 7 vers le terminal de paiement 3, la génération, par le générateur 25 d’identifiants pseudo-aléatoires de transactions au sein du dispositif de paiement 24, de cet identifiant 7 de transaction. C’est donc cet identifiant 7 qui est transmis et utilisé pour générer l’identifiant 18 du ticket numérique, plutôt qu’un identifiant choisi au sein d’une liste. À la transaction suivante sera généré un autre identifiant de transaction. Le système 26 de la FIG. 7 diffère des systèmes précédents en ce que le dispositif de paiement 27 comprend, en plus des composants mentionnés dans les différents modes de réalisation décrits, une clé de chiffrement 19, appelée clé « publique ». Les moyens de transmission 8 sont également aptes à transmettre cette clé de chiffrement 19 au terminal de paiement 3. Une clé de déchiffrement correspondante, dite clé privée, est détenue par une entité extérieure au système, telle qu’une banque ayant émis le dispositif de paiement 27, un portefeuille électronique de l’utilisateur ou l’utilisateur lui-même. En variante, dans un système de chiffrement symétrique, la même clé est utilisée pour chiffrer et pour déchiffrer. Le mode 400 de la FIG. 8 , mis en œuvre par le système 26 de la FIG. 7 , diffère des procédés décrits précédemment en ce qu’il comprend des étapes supplémentaires décrites ci-après. L’étape 401 est la transmission, du dispositif de paiement 27 vers le terminal de paiement 3, de la clé publique de chiffrement 19. L’étape 402 est le chiffrement du ticket numérique 14 généré par la clé de chiffrement. Ce chiffrement est réalisé par le terminal de paiement 3 grâce à la clé obtenue depuis le dispositif de paiement 27. L’étape de transmission 403 à la base de données 5 est alors la transmission non pas du ticket numérique 14 en clair, mais du ticket numérique chiffré 28. C’est ce ticket numérique chiffré 28 qui est associé, dans la base de données 5, à l’identifiant 18 du ticket 14 et à l’horodatage 15. L’intérêt de ce mode 400 est d’empêcher un tiers de réaliser des statistiques à partir des tickets numériques qu’il obtiendrait en clair. Il permet également de gérer des collisions, comme évoqué plus bas, grâce au déchiffrement. Le système 29 de la FIG. 9 diffère des systèmes précédents en ce que les moyens automatisés du terminal de paiement 30 sont en outre aptes à : - recevoir, du dispositif de paiement 2, un identifiant 32 (PAN) du dispositif de paiement 2 ; - générer un identifiant 31 du ticket numérique 14 en réalisant une combinaison entre l’identifiant 32 du dispositif de paiement 2 et l’identifiant 7 de transaction, et en réalisant un hachage d’un résultat de la combinaison. La combinaison est décrite plus bas. Le mode 500 de la FIG. 10 , mis en œuvre par le système 29 de la FIG. 9 , diffère des procédés décrits précédemment en ce qu’il comprend les étapes décrites ci-après. L’étape 501 est, avant la génération de l’identifiant 31, la transmission, depuis le dispositif de paiement 2 vers le terminal de paiement 30, de l’identifiant 32 (« PAN ») du dispositif de paiement. L’étape 502-A est la génération de l’identifiant 31 du ticket numérique. Elle n’est pas réalisée uniquement à partir de l’identifiant de transaction 7 comme dans le procédé 100. Elle est effectuée en réalisant une combinaison entre l’identifiant 32 du dispositif de paiement et l’identifiant 7 de transaction. La combinaison est la concaténation de l’identifiant de transaction 7 à l’identifiant 32 du dispositif de paiement. En variante, l’identifiant de transaction 7 et l’identifiant 32 de la carte sont convertis en nombres binaires, et la combinaison est l’opération XOR entre ces deux identifiants binaires. D’autres types de combinaison sont applicables. C’est le résultat de cette combinaison qui est l’identifiant numérique 31 du ticket 14, et qui est associé au ticket 14 ou au ticket chiffré 28 dans la base de données 5. Dans une variante, l’étape 502-B diffère de l’étape 502-A en ce que le résultat de la combinaison fait l’objet d’une opération de hachage. C’est le hachage du résultat de la combinaison qui est alors l’identifiant 32 numérique du ticket, et qui est associé au ticket 14 ou au ticket chiffré 28 dans la base de données 5. Ce mode 500 améliore encore la sécurité vis-à-vis des modes précédents où seul l’identifiant de transaction est nécessaire pour générer l’identifiant du ticket numérique. Même dans le cas où l’identifiant de transaction est généré de façon purement aléatoire, ce mode est avantageux car il permet la création des identifiants et du dispositif de paiement par des entités respectives distinctes sans confiance entre elles. En effet, dans le cas où une entité A créé uniquement des identifiants de transaction et les transfère à une entité B qui créé le dispositif de paiement et qui génère l’identifiant du dispositif de paiement, la combinaison entre l’identifiant du dispositif de paiement et les identifiants de transaction permet d’éviter que l’entité A, qui aurait stocké les identifiants de transaction générés, essaye d’accéder aux tickets numériques générés à partir de ces identifiants de transaction. Le procédé 600 de la FIG. 11 est un procédé de mise à jour, concernant l’ensemble des modes de mises en œuvre du procédé d’enregistrement décrits précédemment. Il comprend la mise à jour, par un distributeur automatique de billets et au sein du dispositif de paiement 2, de la liste d’identifiants 6 pseudo-aléatoires ou aléatoires de transactions introduite plus haut ou du générateur 25 d’identifiants pseudo-aléatoires introduit plus haut. Ainsi, l’acheteur insert sa carte 2 dans le distributeur de paiement et obtient la possibilité de mettre à jour la liste si la carte fonctionne selon les modes 100 ou 200 ou de mettre à jour le générateur si la carte fonctionne selon le procédé 300. Ce procédé 600 peut être considéré comme formant une étape supplémentaire d’un procédé d’enregistrement selon l’un des modes 100 à 500, ou comme un nouveau mode de mise en œuvre 600 d’un tel procédé d’enregistrement. Dans un autre mode de mise en œuvre non illustré, la liste ou le générateur sont mis à jour via une application mobile de l’utilisateur. Le procédé 700 de la FIG. 12 est un procédé de paiement relatif à une transaction, comprenant, une fois le paiement réalisé, l’enregistrement d’un ticket numérique relatif 14 à la transaction conformément aux modes 100 à 600 du procédé d’enregistrement d’un ticket numérique décrits précédemment. Ainsi, l’utilisateur réalise le paiement au moyen de sa carte de paiement, et le ticket numérique relatif à cette transaction est enregistré dans la base de données conformément aux modes 100 à 600. Le procédé 800 de la FIG. 13 est un procédé de récupération d’un ticket numérique relatif à une transaction, le ticket numérique ayant été enregistré conformément à l’un des modes du procédé d’enregistrements décrits précédemment. L’objectif de l’utilisateur est de récupérer le ticket correspondant à une transaction qu’il a effectuée au préalable. L’étape 801 est obtention de l’identifiant de la transaction. Elle est réalisable étant donné que l’identifiant de transaction est également détenu par une entité externe au système, que ce soit la banque, un portefeuille de l’utilisateur ou l’utilisateur lui-même, conformément aux modes du procédé d’enregistrement décrits précédemment. L’étape 802 est la génération d’un identifiant du ticket numérique à partir de l’identifiant de transaction. Cette étape est la même que celle mise en œuvre par le terminal de paiement dans les différents modes de mise en œuvre du procédé d’enregistrement. Ainsi, si l’identifiant de transaction est l’identifiant numérique, comme dans l’étape 107-A du mode 100, c’est le cas également dans ce procédé de récupération. Si le hachage est nécessaire comme à l’étape 107-B, le même hachage est effectué ici, c’est-à-dire que l’identifiant de transaction fait l’objet de la même fonction de hachage, de façon à générer le même identifiant du ticket numérique si l’identifiant de transaction est identique. De même, si l’identifiant du dispositif de paiement a été combiné à l’identifiant de transaction conformément à l’étape 502-A du mode 500, alors cette étape 802 comprend l’obtention de l’identifiant du dispositif de paiement et la génération de l’identifiant du ticket numérique en réalisant la même combinaison entre l’identifiant du dispositif de paiement et l’identifiant de transaction. En outre, si un hachage a été réalisé comme à l’étape 502-B, alors la même fonction de hachage est appliquée au résultat de la combinaison, de façon à générer le même identifiant du ticket numérique. L’étape 803 est la récupération, dans la base de données de tickets numériques 5, du ticket numérique associé à l’identifiant généré du ticket numérique. L’utilisateur récupère ainsi simplement le ticket numérique relatif à sa transaction, seulement s’il le désire, quand il le désire, et sans que son expérience de paiement n’ait été gênée. L’étape 804 est mise en œuvre si un chiffrement du ticket numérique a été effectué conformément au mode 400 du procédé d’enregistrement. Le ticket ayant été chiffré lors de l’enregistrement, et la clé privée étant détenue par la banque, le portefeuille numérique ou l’utilisateur lui-même, ce ticket numérique récupéré est déchiffré par la clé privée de déchiffrement. L’utilisateur récupère alors le ticket numérique en clair. En variante, dans un système de chiffrement symétrique, la même clé est utilisée pour chiffrer et pour déchiffrer. Les étapes de chiffrement et déchiffrement permettent, en plus d’éviter la réalisation de statistiques sur les tickets en clair, de trancher sur d’éventuelles collisions. En effet, il est théoriquement envisageable que deux identifiants des tickets, pour deux utilisateurs différents, soient identiques. Chaque utilisateur ayant une clé respective de déchiffrement, un utilisateur n’obtiendra que le ticket déchiffré par sa clé et ne pourra accéder au ticket de l’autre utilisateur. L'invention n'est pas limitée aux modes de réalisation présentés et d'autres modes de réalisation apparaîtront clairement à l'homme du métier. En premier lieu, comme déjà évoqué, il apparaîtra clairement à l’homme du métier que certains des modes présentés sont combinables entre eux. Ainsi, le chiffrement ou non du ticket numérique, selon le mode 400, est indépendant des autres étapes du procédé. Les éventuels hachages sont également indépendants des autres étapes. La génération de l’identifiant numérique par la combinaison entre l’identifiant de transaction et l’identifiant du dispositif de paiement diffère de la génération de cet identifiant du ticket effectuée uniquement à partir de l’identifiant de transaction. Cependant, ces deux modes sont une façon de générer l’identifiant du ticket numérique à partir de l’identifiant de transaction, l’un des modes n’ayant pas besoin d’autres éléments, l’autre mode nécessitant en plus l’identifiant du dispositif de paiement. La présence d’une liste d’identifiants dans le dispositif de paiement n’empêche pas la présence d’un générateur d’identifiants, bien que ces deux approchent soient redondantes. La sélection d’un identifiant à une place particulière de la liste et sa suppression n’empêchent pas le comptage des transactions pour sélectionner l’identifiant, bien que là aussi ces deux approches pour sélectionner l’identifiant soient redondantes. On a évoqué la détention de la liste des identifiants de transaction ou du générateur, des fonctions de hachage et de la clé de déchiffrement, par une entité externe telle qu’une banque ou un portefeuille électronique. Il apparaîtra clairement à l’homme du métier que toute autre entité susceptible de permettre à l’utilisateur de récupérer son ticket numérique peut disposer de ces éléments. Il peut s’agir d’une plateforme quelconque associée au système et auprès de laquelle l’utilisateur peut s’identifier et disposer d’un compte privé muni de la liste des identifiants ou du générateur, éventuellement des fonctions de hachage et de la clé de déchiffrement. Le ticket numérique évoqué dans la description correspond à un ticket de caisse. Cependant, tout ticket « relatif à une transaction » est concerné par l’invention. Il peut s’agir d’un ticket de paiement, qui va lister les informations de paiement relatives à la transaction, mais aussi d’un ticket relatif à des informations sur un produit acheté, par exemple comprenant la garantie du produit. L’utilisateur peut ainsi récupérer des informations sur son produit, par exemple la garantie, en accédant à ce ticket quand il le désire. Il peut aussi s’agir d’informations relatives à un billet acheté pour un événement, puisque cet événement est directement associé à la transaction. Liste de références 1 : système d’enregistrement de tickets numériques 2 : dispositif de paiement 3 : terminal de paiement 4 : serveur 5 : base de données 6 : liste d’identifiants de transactions 7 : identifiant de transaction 8 : moyens de communication du dispositif de paiement 9 : support de données du dispositif de paiement 10 : programme d’ordinateur du dispositif de paiement 11 : moyens de communication du terminal de paiement 12 : support de données du terminal de paiement 13 : programme d’ordinateur du terminal de paiement 14 : ticket numérique en clair 15 : horodatage du ticket numérique 16 : support de données du serveur 17 : programme d’ordinateur du serveur 18 : identifiant du ticket numérique 19 : clé de chiffrement 20 : système d’enregistrement de tickets numériques 21 : dispositif de paiement 22 : compteur de transactions 23 : système d’enregistrement de tickets numériques 24 : dispositif de paiement 25 : générateur d’identifiants pseudo-aléatoires de transactions 26 : système d’enregistrement de tickets numériques 27 : dispositif de paiement 28 : ticket numérique chiffré 29 : système d’enregistrement de tickets numériques 30 : terminal de paiement 31 : identifiant du ticket numérique 32 : identifiant du dispositif de paiement 100, 200, 300, 400, 500 : procédé d’enregistrement d’un ticket numérique 600 : procédé de mise à jour d’identifiants de transactions ou d’un générateur d’identifiants 700 : procédé de paiement 800 : procédé de récupération d’un ticket numérique Procédé (100 ; 200 ; 300 ; 400 ; 500 ; 600) d’enregistrement d’un ticket numérique relatif à une transaction, mis en œuvre par ordinateur, caractérisé en ce qu’il comprend les étapes suivantes : - génération (103) d’un ticket numérique (14 ; 28) relatif à une transaction ; - horodatage (104) du ticket numérique (14 ; 28) ; - transmission (106), depuis un dispositif de paiement (2 ; 21 ; 24 ; 27) utilisé pour la transaction vers un terminal de paiement (3 ; 30) utilisé pour la transaction, d’un identifiant de transaction (7) ; - génération (107) d’un identifiant du ticket numérique (18 ; 31) à partir de l’identifiant de transaction (7) ; - transmission (108) du ticket numérique (14 ; 28), de l’identifiant (18 ; 31) du ticket numérique et de l’horodatage (15) du ticket numérique, associés entre eux, vers une base de données (5) de tickets numériques. Procédé (100 ; 200 ; 300 ; 400 ; 600) selon la revendication précédente, dans lequel : - l’identifiant (18) du ticket numérique généré (107-A) à partir de l’identifiant de transaction est l’identifiant de transaction (7), ou - le procédé comprend une étape de hachage (107-B) de l’identifiant de transaction (7) de sorte que l’identifiant numérique (18) généré à partir de l’identifiant de transaction (7) est le résultat du hachage. Procédé (500) selon la revendication 1, comprenant les étapes suivantes : - avant la génération de l’identifiant numérique, transmission (501), depuis le dispositif de paiement (2) vers le terminal de paiement (30), d’un identifiant (32) du dispositif de paiement ; - la génération (502) de l’identifiant (31) du ticket numérique à partir de l’identifiant de transaction (7) est effectuée en réalisant une combinaison entre l’identifiant (32) du dispositif de paiement et l’identifiant de transaction (7), de préférence également en réalisant un hachage (502-B) d’un résultat de la combinaison. Procédé (400) selon l’une quelconque des revendications précédentes, comprenant les étapes suivantes : - transmission (401), du dispositif de paiement (27) vers le terminal de paiement (3), d’une clé de chiffrement (19) ; - chiffrement du ticket numérique (14) généré par la clé de chiffrement (19) ; et dans lequel l’étape de transmission (403) du ticket numérique vers la base de données est la transmission du ticket numérique chiffré (28). Procédé (100 ; 200 ; 400 ; 500 ; 600) selon l’une quelconque des revendications précédentes, comprenant, avant la transmission de l’identifiant de transaction vers le terminal de paiement, une étape de sélection (105), parmi une liste d’identifiants (6) de transaction du dispositif de paiement, de l’un de ces identifiants (7) en vue de transmettre l’identifiant de transaction sélectionné. Procédé selon la revendication précédente (100 ; 200 ; 400 ; 500 ; 600), comprenant : - une étape de comptage (200), par un compteur de transactions (22) du dispositif de paiement (21), du nombre de transactions effectuées par le dispositif de paiement, la sélection de l’identifiant (7) étant réalisée en fonction de ce comptage ; ou - la sélection (105), parmi la liste d’identifiants (6) de transaction du dispositif de paiement, de l’identifiant (7) situé à une extrémité de la liste correspondant à une position de sélection, puis la suppression, dans la liste, de cet identifiant de manière à ce que l’identifiant suivant de la liste se retrouve en position de sélection pour une transaction suivante. Procédé (100 ; 200 ; 400 ; 500 ; 600) selon la revendication 5 out 6, comprenant, au préalable de la transaction, les étapes suivantes : - génération (101) d’une liste (6) d’identifiants pseudo-aléatoires ou aléatoires de transaction ; - enregistrement (102), au sein du dispositif de paiement (2), de cette liste (6) d’identifiants de transaction. Procédé (300) selon l’une quelconque des revendications 1 à 4, comprenant, avant la transmission de l’identifiant de transaction vers le terminal de paiement, une étape de génération (301), par un générateur (25) d’identifiants pseudo-aléatoires du dispositif de paiement (24), de cet identifiant (7) de transaction. Procédé de paiement (700) relatif à une transaction, comprenant, une fois le paiement réalisé, l’enregistrement d’un ticket numérique relatif à la transaction conformément au procédé (100 ; 200 ; 300 ; 400 ; 500 ; 600) selon l’une quelconque des revendications précédentes. Procédé de récupération (800) d’un ticket numérique relatif à une transaction, le ticket numérique (14 ; 28) ayant été enregistré conformément à l’une quelconque des revendications 1 à 8, comprenant les étapes suivantes : - obtention (801) de l’identifiant de la transaction ; - génération (802) d’un identifiant du ticket numérique à partir de l’identifiant de transaction ; - récupération (803), dans la base de données (5) de tickets numériques, du ticket numérique (14 ; 28) associé à l’identifiant (18 ; 31) généré du ticket numérique. Programme d'ordinateur (10 ; 13 ; 17) comprenant des instructions qui, lorsque le programme est exécuté par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes du procédé d’enregistrement (100 ; 200 ; 300 ; 400 ; 500 ; 600) selon l’une quelconque des revendications 1 à 8, du procédé de paiement (700) selon la revendication 9 ou du procédé de récupération (800) selon la revendication 10. Support d'enregistrement (9 ; 12 ; 16) lisible par ordinateur comprenant des instructions qui, lorsqu'elles sont exécutées par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes du procédé d’enregistrement (100 ; 200 ; 300 ; 400 ; 500 ; 600) selon l’une quelconque des revendications 1 à 8, du procédé de paiement (700) selon la revendication 9 ou du procédé de récupération (800) selon la revendication 10. Base de données (5) de tickets numériques, caractérisée en ce qu’elle comprend au moins un ticket numérique (14 ; 28) enregistré conformément au procédé selon l’une des revendications 1 à 8 (100 ; 200 ; 300 ; 400 ; 500 ; 600), le ticket étant associé, dans la base de données, à l’identifiant (18 ; 31) du ticket généré et à l’horodatage (15) du ticket. Dispositif de paiement (2 ; 21 ; 24 ; 27), caractérisé en ce qu’il est spécifiquement configuré pour mettre en œuvre les étapes du procédé d’enregistrement (100 ; 200 ; 300 ; 400 ; 500 ; 600) selon l’une quelconque des revendications 1 à 8, du procédé de paiement (700) selon la revendication 9 ou du procédé de récupération (800) selon la revendication 10, et en ce qu’il comprend: - une liste (6) d’identifiants de transactions ou un générateur (25) d’identifiants pseudo-aléatoires de transactions ; - des moyens de transmission (8), à un terminal de paiement (3 ;30), d’un identifiant de transaction de la liste ou d’un identifiant pseudo-aléatoire généré par le générateur. Terminal de paiement (3 ; 30), caractérisé en ce qu’il est spécifiquement configuré pour mettre en œuvre les étapes du procédé d’enregistrement (100 ; 200 ; 300 ; 400 ; 500 ; 600) selon l’une quelconque des revendications 1 à 8, du procédé de paiement (700) selon la revendication 9 ou du procédé de récupération (800) selon la revendication 10, et en ce qu’il comprend des moyens automatisés aptes à : - recevoir, d’un dispositif de paiement (2 ; 21 ; 24 ; 27), un identifiant (7) de transaction, - générer un identifiant d’un ticket numérique (18 ; 31) relatif à la transaction à partir de l’identifiant de transaction (7) ; - transmettre le ticket numérique (18 ; 31), associé à l’identifiant du ticket numérique généré et à l’horodatage (15) du ticket numérique, vers une base de données (5) de tickets numériques.