QR et contrôle d'accès
La validation est une unique écriture conditionnelle en base de données, jamais une lecture suivie d'une écriture. Deux portes scannant le même code dans la même seconde ne laissent jamais passer qu'une seule personne.
Chacun protège une étape différente de ce qui se passe au moment où un code est scanné.
Le scan utilise la reconnaissance native du navigateur là où elle est disponible, et se rabat sur l'envoi d'une photo partout ailleurs, sans jamais embarquer de bibliothèque de scan dans un cas comme dans l'autre.
Marquer un billet comme utilisé est une écriture unique, conditionnée à son statut encore émis. Deux scans quasi simultanés du même code, depuis deux portes différentes, ne réussissent jamais tous les deux.
Seul le back-office peut invalider un billet ou annuler une validation, jamais l'écran de scan. Donner ces deux pouvoirs au personnel à l'entrée permettrait d'« annuler » un billet utilisé sur place pour laisser entrer une seconde personne avec le même code.
Un fichier de bon n'est jamais servi depuis une URL publique. Chaque téléchargement passe par une route authentifiée qui vérifie aussi que le fichier appartient réellement au billet demandé.
Comment ça se résout
Cinq étapes, à chaque fois qu'un code est scanné ou saisi manuellement.
Un code scanné ou saisi manuellement se résout vers son billet, ou renvoie un « introuvable » clair, sans jamais laisser deviner si ce code a un jour existé.
La validation est un unique UPDATE conditionné à ce que le billet soit toujours émis. Si aucune ligne n'est affectée, rien n'a changé, et la raison est aussitôt rapportée par une nouvelle lecture juste après.
Comme la vérification du statut et l'écriture forment une seule opération atomique, deux portes se disputant le scan du même code au même instant ne peuvent jamais réussir toutes les deux.
Chaque transition, réussie ou non, enregistre qui l'a déclenchée, depuis où, scan ou action d'administration, et quand, si bien qu'une entrée contestée peut toujours être reconstituée.
Annuler une validation ou invalider un billet n'existe que comme action de back-office, derrière sa propre permission, totalement distincte de celle qui permet de scanner à l'entrée.
L'API, telle quelle
Produit, option, type de billet, date, position dans la commande, nom de l'acheteur et statut de traitement. Jamais un prix, jamais une marge, jamais rien dont le personnel à l'entrée n'a pas besoin pour décider.
{
"ticket_code": "AB12CD34EF",
"status": "redeemed",
"redeemed_at": "2026-08-14T10:00:00Z",
"position": 2,
"quantity": 3,
"product_name": "City Food Tour",
"buyer_name": "Jane Buyer",
"fulfillment_status": "not_required"
}Le détail que presque personne n'explique
Quand l'écriture conditionnelle ne touche aucune ligne, cela ne dit pas pourquoi à lui seul. Le système relit aussitôt le billet pour rapporter la cause réelle, déjà validé, avec un horodatage et l'identité de l'auteur, ou invalidé, plutôt qu'un échec générique. Cette vérification a lieu après l'écriture, volontairement : la faire avant rouvrirait exactement la course que l'écriture atomique existe pour fermer.
Non. La validation est une écriture unique en base de données, conditionnée au billet encore émis. Le premier scan à atteindre la base remporte cette condition ; le second trouve zéro ligne affectée et reçoit « déjà validé » à la place.
Pas depuis l'écran de scan. Annuler une validation n'existe que comme action de back-office derrière sa propre permission. Laisser le même personnel scanner et annuler ouvrirait une vraie possibilité de laisser entrer une seconde personne avec un code déjà utilisé.
Non. L'invalidation est définitive par conception ; il n'existe nulle part dans le système de « dé-invalidation ». Une invalidation par erreur nécessite un nouveau billet, pas une annulation.
Non. La réponse de validation se limite volontairement à ce dont le personnel à l'entrée a besoin pour décider : produit, option, type de billet, date, nom de l'acheteur, position dans la commande et statut de traitement.
Ils ne sont jamais servis depuis une URL publique, tout simplement. Chaque téléchargement passe par une route authentifiée qui vérifie aussi que le fichier appartient réellement au billet demandé, pas seulement que le demandeur est connecté.
Tiqory garde disponibilité, tarifs, paiements et accès parfaitement synchronisés à mesure que votre activité grandit. Dites-nous où vous allez ; nous vous montrons comment y arriver sans repartir de zéro.