À l’ouverture des ventes, deux mille personnes demandent les mêmes cinq cents places. Le site affiche encore du stock, le PSP autorise les paiements et le fournisseur de billets répond lentement. Dix minutes plus tard, cent vingt acheteurs possèdent une confirmation de commande, mais aucune place attribuée ; trente autres ont reçu deux billets après un retry.
Le problème ne se réduit pas à la performance. Place, réservation, commande, billet et code de contrôle ont été confondus. Les équipes ne savent plus quel objet engage l’organisateur, lequel doit être remboursé ni quel code reste valide à l’entrée. La correction manuelle augmente la fraude et la charge support.
Le vrai enjeu d’une billetterie dans une marketplace opérateur est de préserver une chaîne de droits depuis l’inventaire jusqu’au contrôle d’accès. Contre-intuitivement, ralentir la file d’achat peut vendre davantage de places valides qu’un checkout rapide qui sur-réserve et compense ensuite.
Vous allez comprendre comment modéliser stock, holds, émission, transfert, scan, report et remboursement, puis les réconcilier. Entrées, sorties, owner, instrumentation, monitoring, dépendances, seuils, file, retry et rollback rendent chaque billet opposable sans exposer l’acheteur aux détails internes.
Définir la promesse de billetterie
Nommer le droit vendu
Le billet peut donner accès à une séance, une zone, un siège, plusieurs jours ou un quota de services. Il peut être nominatif, transférable, remboursable ou soumis à conditions. Ces propriétés sont structurées et affichées avant paiement.
La promesse précise date, lieu, organisateur, placement, restrictions, frais et procédure en cas de changement. Un simple « admission générale » ne suffit pas si plusieurs zones ou créneaux possèdent des capacités distinctes.
Définir les états visibles
En attente de paiement, réservé, confirmé, émis, transféré, utilisé, annulé et remboursé ne sont pas synonymes. La page acheteur traduit ces états avec la prochaine action. L’organisateur reçoit uniquement les informations nécessaires à l’exécution.
Une confirmation de paiement n’affiche pas « billet disponible » avant émission. En revanche, un billet émis reste retrouvable même si l’email échoue. Le compte acheteur devient la source principale de délivrance.
La matrice de responsabilité relie chaque état à Marketplace, Organisateur, PSP, Fournisseur et Contrôle d’accès. Elle évite qu’un partenaire considère sa tâche terminée pendant qu’un autre attend encore une entrée.
Séparer événement, offre et billet
Construire le modèle canonique
L’event décrit le rendez-vous global ; la session porte date et lieu ; la zone ou le siège représente l’inventaire ; le fare définit tarif et conditions ; l’offre seller porte prix et allocation ; le ticket matérialise le droit attribué.
Une commande peut contenir plusieurs tickets et plusieurs participants. Chaque billet possède ticket_id stable, tandis que son code d’accès peut changer. La commande ne sert jamais elle-même de justificatif d’entrée.
Versionner les changements
Horaire, salle, plan, tarif et conditions portent des versions. Une commande conserve leur snapshot. Un déplacement de séance crée une migration ou une proposition acheteur, sans réécrire le contrat historique.
Les identifiants partenaires sont mappés aux objets internes. Une absence ou collision rejoint une file. Le système ne crée pas un deuxième événement parce qu’un organisateur change sa référence technique.
Modéliser places et quotas
Distinguer sièges et admission générale
Un siège possède identité, rang, catégorie, visibilité et état. Une zone libre possède capacité, réservations et ventes. Les deux partagent un ledger d’inventaire, mais pas la même sélection ni la même preuve d’attribution.
Les états possibles sont les suivants : disponible, hold, vendu, bloqué, invité, libéré ou indisponible. Chaque transition cite source et version. Un blocage technique ne devient pas une vente, et une invitation consomme réellement la capacité.
Un plan de salle possède lui aussi une version. Déplacer un siège, fusionner deux zones ou fermer une rangée ne modifie pas les billets déjà vendus sans workflow dédié. La projection compare le plan courant aux attributions et signale immédiatement toute place devenue inexistante ou située dans une zone différente.
Gérer quotas et contingents
L’organisateur peut répartir un même stock entre marketplace, guichet, partenaires et invitations. Le quota possède plafond et période, mais la capacité physique reste commune. Les allocations sont réconciliées pour empêcher la survente intercanal.
Une réallocation de quota ne duplique pas les places déjà vendues. Elle transfère seulement le disponible avec transaction et numéro de séquence. Les modifications importantes sont simulées avant publication.
Le monitoring suit disponible total, holds, ventes et blocages. Toute équation incohérente gèle les nouvelles réservations de la session, sans annuler les billets déjà valides.
Réserver sans survente
Créer un hold atomique
Le service reçoit session, sièges ou quantité, fare, expires_at et idempotency_key. La création vérifie disponibilité et réserve dans une même opération. Deux acheteurs ne peuvent pas obtenir le même siège par lectures concurrentes.
Le hold possède durée visible et propriétaire. Il survit à un refresh mais pas à son échéance. Le client affiche un compte à rebours synchronisé avec le serveur, jamais une durée inventée localement.
Pour des places contiguës, la réservation porte le groupe complet ou échoue. Elle ne laisse pas l’acheteur avec deux sièges séparés après une concurrence partielle. Le moteur peut proposer une autre rangée, mais cette alternative nécessite un nouveau hold et une confirmation visible avant paiement.
Expirer et réguler la demande
Le worker libère les holds expirés par événement idempotent. Un paiement arrivé juste après expiration suit une procédure de vérification ; il ne ressuscite pas automatiquement une place déjà vendue à quelqu’un d’autre.
Une waiting room limite les entrées selon capacité de réservation et de paiement. Le token de file ne réserve pas de place. Il donne un droit temporaire d’accéder au checkout, signé et non transférable selon policy.
Si le taux de timeout dépasse 5 % ou si le lag de libération excède trente secondes, alors le débit diminue. Le système protège l’intégrité avant d’augmenter le nombre d’acheteurs simultanés.
Qualifier organisateurs et droits
Vérifier l’autorité de vendre
L’organisateur fournit identité, mandat, événements couverts, capacité, conditions et coordonnées de règlement. La marketplace conserve sources, dates et versions. Un document général ne suffit pas pour chaque événement.
Les vendeurs secondaires ou distributeurs déclarent origine des billets et droits de revente. La policy peut interdire certaines catégories ou exiger un transfert officiel. Une capture de billet n’est pas une preuve de propriété.
La capacité déclarée est rapprochée du plan, du contrat de salle et des autres canaux. Par exemple, un organisateur qui attribue cinq cents places à trois distributeurs ne peut pas conserver le même quota disponible sur chacun. L’écart bloque l’ouverture jusqu’à une ventilation cohérente.
Contrôler publication et changements
Date, lieu, capacité, plan et politique de remboursement passent des quality gates. Une modification après ventes montre l’impact : commandes, participants, paiements et notifications. Les champs sensibles exigent double approbation.
Le back-office sépare brouillon, publié, suspendu, annulé et terminé. Suspendre les ventes ne désactive pas les billets émis. Annuler l’événement déclenche un workflow distinct avec décision financière.
Payer puis émettre sans doublon
Orchestrer paiement et consommation du hold
La saga crée la commande, autorise ou capture selon modèle, consomme le hold puis émet les billets. Chaque étape écrit état, tentative et compensation. Le coût d’irréversibilité détermine l’ordre.
Le hold_id et checkout_request_id servent de clés racines. Un double clic ou callback PSP répété retourne la même commande. Une place ne peut être consommée par deux order_lines.
Émettre une attribution stable
Le ticket est créé avec participant, session, place, fare et order_line. Le fournisseur externe reçoit une clé idempotente et renvoie sa référence. Une réponse perdue est vérifiée avant retry.
Si l’émission échoue après paiement, alors la commande passe ISSUE_PENDING et rejoint une file. Le système tente dans la limite du hold consommé. Il rembourse seulement lorsque l’attribution ne peut plus être garantie.
Les entrées sont order_version, payment, hold et participants ; les sorties sont tickets, références, allocations et anomalies. Ticketing possède le droit, Finance le mouvement et Operations la reprise.
Protéger le billet et son code
Séparer identité et jeton d’accès
Ticket_id demeure stable ; le barcode ou QR est un jeton vérifiable, éventuellement rotatif. Une capture d’écran ancienne peut devenir invalide sans supprimer le billet. Le compte authentifié affiche la version courante.
Le token contient peu de données, possède signature, audience et échéance adaptées. Les informations personnelles ne sont pas encodées en clair pour faciliter le scan. Les secrets de signature sont rotatés avec plan de compatibilité.
La rotation prépare simultanément validateurs en ligne et appareils hors ligne. Une fenêtre accepte l’ancienne clé pour les billets déjà chargés, puis son retrait est confirmé porte par porte. Si un appareil ne reçoit pas la nouvelle liste, alors il reste fermé plutôt que de valider sans signature.
Détecter copie et extraction
Plusieurs affichages ne signifient pas fraude. En revanche, scans simultanés, appareils nombreux ou exports massifs déclenchent une revue. La mesure distingue consultation légitime, transfert et tentative d’usage multiple.
Les billets ne sont jamais envoyés en pièce jointe permanente lorsque la révocation doit rester possible. Une notification mène vers un accès contrôlé. Le support régénère le moyen d’accès sans créer un nouveau droit.
Gérer transfert et revente
Transférer la titularité atomiquement
Le propriétaire initie une invitation avec destinataire, délai et conditions. Tant qu’elle n’est pas acceptée, le billet reste dans un état borné. À l’acceptation, l’ancien code est révoqué et le nouveau bénéficiaire reçoit un accès.
Le transfert est idempotent et versionné. Une invitation expirée ne change rien. Le journal relie ancien et nouveau détenteurs selon les droits d’accès autorisés, sans exposer inutilement leurs données.
Encadrer la revente
L’offre secondaire référence ticket, prix, plafond éventuel et autorisation. Le billet est verrouillé pendant la vente. Après paiement, la titularité et les mouvements financiers basculent dans une même saga.
Une revente échouée libère le billet au propriétaire initial. Les commissions, remboursements et obligations suivent le contrat applicable. La marketplace ne laisse pas coexister ancien code et nouvelle attribution.
Le graphe de provenance conserve émission, transferts et reventes. Il permet de traiter un report ou remboursement sans payer deux détenteurs ni perdre le bénéficiaire courant.
Contrôler l’accès même hors ligne
Décider au scan
Le contrôleur vérifie signature, session, statut, fenêtre et usage précédent. Le résultat est accepté, déjà utilisé, invalide, révoqué ou revue. Chaque scan porte device_id, gate, time et rule_version.
Un scan accepté consomme le droit atomiquement en ligne. Les doublons sont rejetés avec contexte minimal. Un superviseur peut autoriser une exception avec reason code, sans effacer la première tentative.
Préparer le mode hors ligne
Les appareils chargent une liste signée, bornée à leur session et leur porte. Ils conservent les scans localement avec séquence. Les quotas empêchent deux portes hors ligne d’accepter le même sous-ensemble si le risque l’exige.
À la reconnexion, les événements se synchronisent et les conflits rejoignent une file. Le runbook couvre appareil perdu, horloge fausse, liste périmée et clé compromise. Le mode dégradé est testé sur site.
Traiter annulation et report
Versionner la décision organisateur
Annulation, report, changement de lieu et modification substantielle sont des événements distincts. Le dossier cite décision, périmètre, date, policy et options acheteur. Il fige la population concernée.
Un report peut proposer conserver, échanger ou demander remboursement selon conditions validées. Le choix possède échéance. L’absence de réponse ne devient pas un consentement si la policy ne le prévoit pas.
Les sièges d’une nouvelle salle ne correspondent pas toujours aux anciens. Le remapping produit des propositions selon catégorie, visibilité et proximité, puis l’acheteur confirme lorsque la qualité change. Les places sans équivalent rejoignent une file prioritaire avec alternative et possibilité de remboursement.
Réconcilier droits et argent
Le remboursement part du ticket courant et de sa provenance. Un billet transféré peut rembourser l’acheteur initial ou le détenteur selon le contrat ; la règle est explicite. Le code est révoqué au moment approprié.
Les frais, commission, prix et taxes sont ventilés depuis le snapshot. PSP, ledger, seller balance et ticket sont rapprochés. Un remboursement initié n’est pas affiché comme reçu.
Le batch utilise manifest et idempotency_key. Un retry ne rembourse pas deux fois. Les échecs isolés rejoignent une file avec montant, ticket, source et prochaine action.
Piloter fraude, support et qualité
Mesurer le funnel complet
Le tableau suit file d’attente, holds, conversion, paiements, émissions, transferts, scans, refus, remboursements et support. Il segmente événement, organisateur, canal et appareil pour isoler les causes.
Vendre toutes les places n’est pas suffisant si beaucoup de billets arrivent tard ou échouent au contrôle. Le coût inclut PSP, support, fraude, opérations sur site et compensations.
Détecter les signaux faibles
Des holds expirés en hausse signalent un checkout lent. Des billets consultés depuis de nombreux appareils peuvent annoncer une extraction. Des scans invalides concentrés sur une porte indiquent plutôt un problème de synchronisation.
Le monitoring couvre capacité, files, PSP, émission, clés, appareils et remboursements. Chaque alerte possède seuil, owner et runbook. Un mode dégradé ferme les nouvelles ventes sans invalider les billets déjà émis.
Adapter la méthode et éviter les erreurs
Pour qui cette architecture de billetterie convient
Elle concerne événements, loisirs, transport ou rendez-vous lorsque capacité et contrôle doivent rester cohérents. Une petite marketplace commence avec admission générale, transfert interdit et un seul fournisseur avant d’ajouter le placement.
Inventory possède les places, Orders la commande, Ticketing le droit, Payments les mouvements, Venue le contrôle et Support la reprise. L’organisateur garde ses décisions dans un cadre auditable.
Erreurs fréquentes de la billetterie
Utiliser le paiement comme preuve de billet, réserver sans expiration, réémettre après retry, envoyer un QR permanent et supprimer l’ancien détenteur au transfert sont les erreurs majeures.
Une autre erreur consiste à tester uniquement en ligne. Enfin, rembourser depuis un fichier de commandes sans vérifier titularité et état du ticket crée doublons et fraude. Le ledger de droits reste central.
Plan d’action pour lancer la billetterie
Semaines 1 à 4 : inventaire et émission
La première semaine ferme objets, états et responsabilité. La deuxième construit ledger de places et holds. La troisième branche paiement et émission. La quatrième sécurise codes, compte acheteur et preuve.
Les tests couvrent concurrence, expiration, timeout PSP, double callback, émission perdue, transfert, double scan, mode hors ligne, annulation et remboursement. Chaque cas attend états et compensations.
Le corpus de charge reproduit l’ouverture réelle : file d’attente, pics sur quelques zones, paniers abandonnés et reprise de paiement. Les tests vérifient l’équation d’inventaire après chaque palier, puis rejouent les mêmes clés pour confirmer qu’aucun retry ne consomme une nouvelle place.
Semaines 5 à 8 : exploitation et pilote
La cinquième semaine outille support et organisateur. La sixième teste contrôle sur site et monitoring. La septième ouvre une session pilote ; la huitième provoque pic, panne, report et rollback.
Les entrées sont sessions, inventaires, holds, commandes et participants ; les sorties sont tickets, scans, mouvements et anomalies. L’instrumentation suit latence, files, doublons et coût. Le runbook nomme owners.
Le go exige zéro place vendue deux fois, émission idempotente, scan hors ligne réconcilié et remboursement complet. Une personne extérieure doit reprendre un callback perdu et invalider un code transféré.
Si plus de 1 % des paiements attendent un billet ou si le p95 d’émission dépasse deux minutes, alors le débit reste limité. L’équipe corrige capacité et fournisseur avant une nouvelle session.
- À faire d’abord : fermer objets, ledger de places, hold et stratégie de paiement.
- À tester ensuite : émission, code, transfert, scan, changement et remboursement.
- À différer : la revente tant que le transfert simple n’est pas réconcilié.
- À refuser : toute confirmation qui ne possède ni place attribuée ni chemin de compensation.
Ressources complémentaires opérateur
Borner le premier périmètre
Le MVP marketplace avant ouverture aide à choisir les capacités indispensables.
La méthode pour ouvrir une première catégorie fournit une session pilote cohérente.
Structurer catalogue et exploitation
Le catalogue PIM marketplace gouverne événements, tarifs et conditions.
Les écrans du back-office opérateur réunissent commande, billet, scan et remboursement.
Conclusion : gouverner la place jusqu’à l’entrée
Une billetterie fiable sépare inventaire, hold, commande, billet et code avant d’ouvrir les ventes.
Atomicité, idempotence et provenance protègent chaque place pendant paiement, émission, transfert et scan.
Report, remboursement, monitoring et support rendent la promesse réparable lorsque l’événement change. Cette continuité donne aussi aux équipes sur site une décision fiable même pendant un pic ou une perte de réseau.
Dawap peut vous accompagner pour construire cette verticale dans votre marketplace opérateur.
