Un code et un QR, jamais un simple nombre
Chaque billet porte un court code imprimable et son propre QR, généré directement à partir de ce code, prêt à être validé seul, quel que soit le nombre d'autres billets dans la même commande.
Commandes et billets
Chaque place reçoit son propre code. Jamais un simple décompte.
Achetez trois places, recevez trois billets individuellement validables, chacun figé au prix et à la politique en vigueur au moment de l'achat. Un changement de catalogue la semaine prochaine ne réécrit jamais une vente déjà conclue.
- 1 billet par unité Achetez trois places, recevez trois codes individuellement validables, jamais une simple quantité
- Figé à l'achat Nom du produit, type de billet, prix et politique d'annulation ne changent jamais après la vente, même si le catalogue change
- Séquentiel par organisation Les numéros de reçu s'incrémentent sous verrou de ligne, si bien que deux commandes payées au même instant ne se percutent jamais
Quatre éléments du traitement des commandes.
Chacun couvre une étape différente de la transformation d'une commande payée en quelque chose que le client peut réellement utiliser.
Tout ce qui est commercial est figé
Produit, option, type de billet, prix et politique d'annulation sont recopiés sur la commande au moment même où elle est payée. Un changement de prix la semaine prochaine ne réécrit jamais ce que quelqu'un a déjà payé.
Bons externes, suivis à part
Un billet nécessitant un bon d'un tiers porte son propre statut de traitement, indépendant de sa validité d'entrée, si bien que le personnel à l'accès sait toujours si un code reste à rattacher.
Un historique complet, pas seulement un état actuel
Chaque changement de statut, émis, annulé, validé, écrit un événement enregistrant qui l'a modifié et depuis quelle source : un agent, le système, ou un webhook de paiement.
Comment ça se résout
Comment une commande payée devient de vrais billets
Cinq étapes, depuis la confirmation du paiement jusqu'au moment où le client tient un code en main.
- 1
La commande reçoit son numéro de reçu
Juste après la confirmation du paiement, la ligne compteur de l'organisation se verrouille brièvement, s'incrémente, et ce numéro est attribué. Deux commandes payées à la même seconde exacte reçoivent tout de même deux numéros distincts et séquentiels.
- 2
Un billet naît par unité
Acheter trois unités du même type de billet crée trois lignes de billet distinctes, chacune avec sa propre position dans la commande, jamais une seule ligne portant un champ de quantité.
- 3
Un code est généré, vérifié contre les collisions
Un code de dix caractères, tiré d'un alphabet excluant les caractères visuellement ambigus comme 0 et O, est généré puis vérifié comme unique au sein de l'organisation avant d'être attribué.
- 4
Le QR est construit à partir du seul code
Le QR encode exactement le code du billet et rien d'autre, intégré directement dans l'e-mail de confirmation plutôt qu'envoyé en pièce jointe séparée.
- 5
L'e-mail attend que la base de données le confirme vraiment
La confirmation ne se met en file d'attente qu'une fois la transaction de paiement réellement validée, si bien qu'un client ne reçoit jamais de billet pour une commande qui, quelques instants plus tard, a en réalité échoué.
L'API, telle quelle
Un billet porte toute son histoire
Position dans la commande, produit, type de billet, date, nom de l'acheteur et statut de traitement, résolus à partir du seul code. Le prix et le coût n'apparaissent jamais ici, volontairement.
GET /api/v1/tickets/lookup
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
{
"ticket_code": "7K3P9QXFH2",
"status": "issued",
"position": 2,
"quantity": 3,
"product_name": "City Food Tour",
"pricing_category_name": "Adult",
"date": "2026-08-14",
"fulfillment_status": "not_required"
}200 Billet résolu
Le détail que presque personne n'explique
Un bon en attente ne bloque jamais l'entrée
Un billet encore en attente d'un bon externe peut malgré tout être validé. Le personnel à l'accès voit un avertissement clair « à vérifier manuellement » plutôt qu'un blocage strict, car un opérateur ne contrôle pas toujours le moment où arrive un code tiers, et refuser l'entrée pour un simple écart de paperasse serait la mauvaise réaction.
Questions fréquentes
Quatre. Chaque unité vendue devient son propre billet, avec son propre code, son propre QR et sa propre position dans la commande, si bien que chacun peut être validé indépendamment des autres.
Rien. Le prix, le nom du produit, le type de billet et la politique d'annulation sont tous figés sur la commande au moment où elle est payée. Un changement de catalogue ultérieur est invisible pour une vente déjà conclue.
La ligne compteur propre à l'organisation est verrouillée le bref instant où elle est lue puis incrémentée, si bien que deux commandes confirmées au même instant exact reçoivent tout de même deux numéros distincts et séquentiels, jamais de collision.
Il porte son propre statut de traitement, distinct de sa validité d'entrée. Le personnel à l'accès voit un avertissement clair l'invitant à vérifier manuellement jusqu'à ce qu'un agent rattache le vrai code ou PDF, mais le billet n'est jamais bloqué à la validation en attendant.
Non. Il ne se met en file d'attente qu'une fois validée la transaction de base de données qui marque la commande comme payée, ce qui ferme la brèche où un e-mail pourrait partir pour un achat qui, un instant plus tard, s'avère avoir échoué.
Plus de réservations. Plus de canaux. Le même calme.
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.