Intégrer la sélection de sièges dans un module de vente

Ce guide explique comment proposer le choix des places dans votre module de vente StockTicket, puis reprendre ces choix dans le panier. L'interface de sélection est fournie par un autre module sous forme de WebComponent, un élément HTML personnalisé que vous affichez dans votre page.

La sélection sur plan ne se limite pas aux sièges numérotés : l'utilisateur peut choisir un siège précis, mais aussi demander, par exemple, trois places dans une zone en placement libre, assise ou debout. Le composant peut proposer ces deux types de choix sur un même plan. Votre module de vente suit le même parcours d'intégration dans les deux cas ; il n'a pas à traiter lui-même les adresses de sièges ou les quantités par zone.

Pour intégrer cette interface, StockTicket fournit SeatSelectionHost, une aide JavaScript qui charge le composant et vous transmet son résultat. Vous conservez les appels à l'API et la gestion de votre parcours de vente ; vous n'avez ni plan à dessiner ni échanges de sélection à implémenter.

Les appels à l'API StockTicket sont exclusivement serveur à serveur. Le serveur de votre module de vente effectue les appels catalogue, ouverture de session, application au panier et révocation, avec sa clé Stk-Api-Key et depuis une IP autorisée. Le navigateur échange avec votre propre serveur pour ces opérations et ne reçoit jamais cette clé. Le module de vente et l'API StockTicket peuvent être hébergés sur des serveurs et domaines différents. Seuls le chargement des fichiers JavaScript publics et les échanges du composant avec le canal de sélection, au moyen du jeton délégué, se font directement depuis le navigateur vers StockTicket.

Le guide du module de sélection concerne le fournisseur du composant, pas les tâches à réaliser dans votre module de vente.

1. Répartition des responsabilités

Une représentation est appelée EventDate dans les contrats, et son identifiant est eventDateId.

Le parcours à intégrer

1. Depuis votre serveur, lire le détail de la représentation pour savoir si une interface de sélection est proposée et obtenir l'adresse de son fichier JavaScript.
2. Depuis votre serveur, demander à StockTicket d'ouvrir une session de sélection : elle rassemble les choix pour cette représentation et votre contexte de vente. Transmettre les informations de lancement à votre page.
3. Afficher le composant avec SeatSelectionHost, en lui transmettant les informations de connexion retournées par StockTicket.
4. Laisser l'utilisateur choisir ses places dans le composant. Celui-ci échange directement avec StockTicket pour lire le plan et enregistrer les choix. Les nouvelles places acceptées sont retenues temporairement pour la session : ce sont les blocages provisoires, avant leur application au panier.
5. Recevoir son résultat : Annuler pour quitter sans modifier le panier, ou OK pour récupérer les choix confirmés. Après OK, StockTicket peut fournir une référence de sélection, une chaîne qui désigne ces choix.
6. S'il y a une référence, la transmettre à votre serveur, qui l'envoie à l'API panier. Afficher ensuite le panier réellement retourné par StockTicket.

flowchart LR
    V[Page de vente dans le navigateur] -->|Demandes de lancement et référence à appliquer| S[Serveur du module de vente]
    S -->|Appels serveur à serveur avec clé API| A[API StockTicket]
    A -->|Lancement ou panier obtenu| S
    S -->|Informations de lancement ou panier à afficher| V
    V -->|SeatSelectionHost : création et paramètres| C[WebComponent dans le navigateur]
    C <-->|Plan et choix avec jeton délégué| H[Canal SignalR StockTicket]
    C -->|Résultat OK ou Annuler confirmé| V

Qui implémente quoi ?

• Le serveur de votre module de vente effectue les requêtes API : catalogue, ouverture, application au panier et révocation explicite si nécessaire. Il conserve la clé d'API et transmet les informations de lancement et le panier obtenu à votre page.
• Votre page et SeatSelectionHost chargent le JavaScript du fournisseur, créent le composant, transmettent ses propriétés et traitent ses événements. Sur OK avec une référence, la page la transmet à votre serveur selon les échanges propres à votre application. Elle ne reçoit jamais votre clé d'API.
• Le WebComponent utilise l'autorisation de session reçue pour lire le plan et modifier la sélection ; il confirme aussi OK ou Annuler auprès de StockTicket avant de vous en informer.
• StockTicket contrôle les droits, arbitre les disponibilités et retourne le panier effectivement obtenu.

Votre serveur appelle l'API avec l'authentification habituelle de votre module de vente et, si votre parcours le prévoit, le client identifié. StockTicket utilise ce contexte pour contrôler les droits et les tarifs. Le composant n'a pas à recevoir votre clé ni à reconstruire ces identités.

La séparation importante est donc : le composant termine les choix ; votre module de vente les fait appliquer au panier. OK ne signifie ni panier déjà constitué ni achat validé.

2. Préparer la configuration et découvrir le fournisseur

Votre module de vente doit d'abord déclarer qu'il sait intégrer une sélection de places sur plan, numérotées ou en placement libre. Ensuite, pour chaque représentation, il interroge le catalogue plutôt que de choisir lui-même un fournisseur ou de coder son adresse en dur.

1. Activer AllowSeatSelection sur la définition de votre module de vente, qu'il soit à encaissement paramétrable (SellingCustomPayee) ou intégré (SellingFixedPayee). L'indicateur est désactivé par défaut.
2. Depuis le serveur du module de vente, lire le détail de la représentation avec POST /api/client/v1/Catalog/GetEventDateDetail?eventDateId=... sur l'API StockTicket.
3. Si la sélection est proposée, récupérer seatSelectionInfos.webComponentUrl dans le détail retourné:

{
  "seatSelectionInfos": {
    "webComponentUrl": "https://fournisseur.example.test/seat-picker.js"
  }
}

Le bloc est nul ou absent si la sélection sur plan n'est pas proposée pour cette représentation. Votre code doit alors conserver son parcours de vente sans sélection sur plan.

webComponentUrl est l'adresse du module JavaScript ES à charger, pas celle d'une page HTML à afficher. Conserver cette valeur pour la transmettre à SeatSelectionHost au paragraphe 4. Elle ne donne pas encore accès à une session : celle-ci est ouverte à l'étape suivante.

3. Ouvrir une session

Une fois le fournisseur connu, votre serveur demande à StockTicket d'ouvrir la session. Cette demande fixe la représentation et le contexte de vente dans lequel les choix seront autorisés. Si vous fournissez un panier existant, le composant pourra montrer les places déjà réservées pour cette représentation.

Depuis votre serveur, effectuer un POST HTTPS sur /api/client/v1/SeatSelection/OpenSession, avec eventDateId dans les paramètres de l'URL. Aucun corps n'est requis. Utiliser votre authentification habituelle dans Stk-Api-Key, et Stk-Cust-Id si votre parcours identifie déjà un client. Tous les chemins d'API de ce guide se rapportent à l'adresse de l'API StockTicket configurée sur votre serveur, pas au domaine de la page de vente. Ajouter le préfixe de déploiement si l'API est hébergée sous un chemin applicatif.

Informations retournées à l'ouverture

StockTicket répond à votre serveur avec 200 et les informations nécessaires pour lancer le composant. Votre serveur les transmet ensuite à votre page :

{
  "sessionId": "identifiant-de-session",
  "hubUrl": "https://api.example.test/hubs/seat-selection",
  "token": "jeton-delegue-a-ne-pas-journaliser",
  "expiresAtUtc": "2030-06-10T14:15:00Z"
}

Vous disposez maintenant de deux adresses aux rôles distincts : webComponentUrl, obtenu au catalogue, sert à charger le JavaScript du fournisseur ; hubUrl, obtenu à l'ouverture, sert au composant pour communiquer avec StockTicket.

La réponse porte Cache-Control: no-store pour éviter de la mettre en cache ou de la journaliser.

Paramètres facultatifs d'ouverture

• basketId désigne votre panier courant. À l'ouverture, il sert uniquement à lire les réservations initiales de cette représentation : le panier n'est pas modifié. S'il est absent ou illisible, la session s'ouvre sans sélection initiale.
• allowedOrigin permet de limiter l'usage de la session à la page de vente. Une origine est la combinaison du protocole, du domaine et du port éventuel, comme https://vente.example.test:8443 ; dans le navigateur, location.origin fournit cette valeur. Votre serveur transmet à StockTicket l'origine autorisée de votre page de vente, pas celle du fichier JavaScript fournisseur ni celle du serveur du module de vente. La valeur doit être HTTPS, sans chemin, joker, identifiants, paramètres ni fragment. Si elle est omise, vide ou blanche, ce contrôle est désactivé.

Vous pouvez maintenant afficher le composant avec ces informations. Il conserve le même jeton pendant la session ; votre code n'a aucun appel de prolongation ni remplacement de jeton à programmer. Les cas d'expiration et d'abandon sont expliqués après le parcours complet, au paragraphe 6.

4. Utiliser l'aide visuelle

À ce stade, vous avez l'URL du fournisseur issue du catalogue et les informations de session retournées à l'ouverture. SeatSelectionHost les utilise pour créer le composant et l'insérer dans une zone de votre page.

L'aide est fournie par StockTicket dans un module JavaScript public. Le fournisseur charge dans son composant la bibliothèque de communication avec StockTicket, appelée SDK de sélection ; vous chargez seulement l'aide visuelle.

Charger l'aide et préparer l'affichage

Importer SeatSelectionHost pour gérer le composant, et SeatSelectionHostError pour traiter les erreurs de son chargement :

import { SeatSelectionHost, SeatSelectionHostError }
    from "https://api.example.test/seat-selection/js/seat-selection-host.js";

const host = new SeatSelectionHost();

Adapter le domaine à votre API. Si elle est hébergée sous /stk/, le fichier est sous /stk/seat-selection/js/seat-selection-host.js. La version minifiée seat-selection-host.min.js, dans le même répertoire, expose la même API.

Pour les projets TypeScript, les déclarations de types de l'aide sont disponibles sur le serveur de l'API à l'adresse seat-selection/dist/js/seat-selection-host.d.ts, avec le même domaine et le même préfixe de déploiement. Elles décrivent ses classes, méthodes et paramètres pour l'autocomplétion et la vérification des types à la compilation.

Prévoir un élément HTML dans votre page pour accueillir la sélection, par exemple un panneau ou le contenu d'une fenêtre modale. Dans les extraits suivants, container désigne cet élément, déjà inséré dans le document, detail les données catalogue transmises par votre serveur au paragraphe 2 et launch les informations d'ouverture transmises par votre serveur au paragraphe 3. Ces extraits s'exécutent dans le navigateur et n'effectuent aucun appel à l'API StockTicket.

Recevoir le résultat du composant

Le composant demande lui-même à StockTicket de confirmer la fin des choix. Il vous en informe ensuite par un événement dans la page, que l'aide relaie sur l'instance host. Vous installez les écouteurs avec host.addEventListener(...) ; les données d'un événement sont accessibles dans event.detail.

Ces événements navigateur ne sont pas des requêtes réseau. Votre code doit réagir à chacun d'eux :

Installer ces écouteurs avant de demander l'affichage, car le composant peut retrouver une session déjà terminée dès sa connexion :

host.addEventListener("stk-seatselection-ok", event => {
    host.unmount();
    // Transmet la référence à votre serveur si event.detail.hasSelection vaut true (paragraphe 5).
});
host.addEventListener("stk-seatselection-cancel", () => {
    host.unmount();
    // Votre interface revient au parcours de vente sans appliquer de sélection.
});
host.addEventListener("stk-seatselection-expired", () => {
    host.unmount();
    // Votre interface explique que le délai est écoulé et propose de recommencer.
});
host.addEventListener("stk-seatselection-error", event => {
    // Affiche un message adapté à event.detail.code, sauf pour None qui n'est pas une erreur.
});

// Les écouteurs sont maintenant prêts : affiche le composant dans la zone réservée.
await host.mount(container, {
    webComponentUrl: detail.seatSelectionInfos.webComponentUrl,
    hubUrl: launch.hubUrl,
    token: launch.token
});

mount() charge le fichier du fournisseur, appelle sa fonction de création, affecte les propriétés de connexion puis insère l'élément dans votre page. Le fournisseur gère son nom de balise, sa connexion à StockTicket et les interactions de sélection : vous n'avez pas à réimplémenter ces opérations.

Référence de l'aide et nettoyage

Quand vous fermez cette interface, appeler host.unmount(). L'aide retire l'élément et ses écouteurs internes ; le composant du fournisseur arrête sa connexion au retrait. Cela ne demande pas d'abandon métier à StockTicket. Le paragraphe 6 distingue cette fermeture d'une annulation ou d'une révocation.

Vous restez responsable des écouteurs que votre page a installés sur host. Les retirer quand la page est détruite, ou les associer à un AbortSignal, qui permet de les retirer ensemble. Les événements relayés s'écoutent sur host, pas sur le document HTML.

Si un montage est remplacé pendant le chargement, l'aide empêche son élément d'être inséré tardivement. Vous pouvez réutiliser la même instance hôte pour une autre sélection en lui fournissant ses nouveaux paramètres.

Erreurs de montage : SeatSelectionHostError.code

Un problème de chargement peut survenir avant même que le composant soit affiché. Dans votre code, entourer await host.mount(...) d'un try/catch, puis lire SeatSelectionHostError.code. Ce rejet de promesse n'est pas aussi publié comme événement d'erreur du composant.

Erreurs du composant : stk-seatselection-error.detail.code

Ces erreurs arrivent par l'écouteur de stk-seatselection-error installé sur host. Elles concernent le parcours dans le composant, pas forcément vos appels API. Lire le code pour choisir le message et l'action à proposer, sans recopier de données de connexion dans les diagnostics.

L'aide ne relaie que ces codes ; un code fournisseur inconnu ou un résultat OK mal formé devient ProtocolError. Le composant gère les états de connexion, la consultation du plan et les modifications de sélection avec son SDK : votre module de vente n'a pas à interpréter ces échanges. Leur référence figure dans le guide du fournisseur.

5. Appliquer la référence au panier

Quand votre page reçoit OK avec hasSelection: true, le composant a terminé son travail : les choix sont confirmés côté StockTicket, mais votre panier n'a pas encore été modifié. Votre page transmet la référence reçue à votre serveur. Celui-ci appelle l'opération API Basket/ApplySeatSelection, puis renvoie le panier obtenu à la page selon les échanges habituels de votre application.

Cette opération ne consiste pas seulement à ajouter des billets : elle met le panier en accord avec les choix finaux pour la représentation concernée. Elle peut donc conserver des billets, en ajouter, en retirer ou changer leur tarif. Les autres représentations du panier ne sont pas remplacées.

Le parcours complet est le suivant :

sequenceDiagram
    participant N as Page de vente (navigateur)
    participant V as Serveur du module de vente
    participant C as WebComponent (navigateur)
    participant A as API StockTicket
    participant H as Canal SignalR StockTicket
    N->>V: Demande de sélection
    V->>A: Catalogue : descripteur du fournisseur
    V->>A: OpenSession(eventDateId, basketId, allowedOrigin)
    A-->>V: sessionId, hubUrl, token, expiresAtUtc
    V-->>N: URL fournisseur et informations de lancement
    N->>C: SeatSelectionHost : chargement, propriétés, insertion
    C->>H: Consultation et mutations via SDK et jeton délégué
    H-->>C: Sélection et blocages confirmés
    C->>H: Termine les choix par OK via son SDK
    H-->>C: Référence confirmée
    C-->>N: stk-seatselection-ok
    N->>V: Référence à appliquer
    V->>A: ApplySeatSelection(selectionReference, basketId)
    A-->>V: 201 : panier réellement utilisé et validation
    V-->>N: Panier obtenu et messages de validation
    Note over N: Reprend basketId et tout le contenu retourné

Envoyer la référence et reprendre le panier retourné

Depuis le serveur de votre module de vente, effectuer ce POST HTTPS vers l'API StockTicket avec votre authentification habituelle. Ce bloc décrit la requête serveur à serveur, pas un appel JavaScript navigateur :

POST /api/client/v1/Basket/ApplySeatSelection?basketId=panier-courant
Stk-Api-Key: authentification-habituelle-du-module-de-vente
Content-Type: application/json

{ "selectionReference": "reference-recue-sur-ok" }

basketId est facultatif. Le corps contient uniquement selectionReference, pas une liste de places, une quantité ou des tarifs choisis à nouveau par votre code.

StockTicket répond avec 201 et un BasketDetailModel, le détail du panier obtenu. Votre code doit alors :

1. Conserver le basketId retourné, même si vous aviez déjà fourni un identifiant : StockTicket peut créer un nouveau panier si l'ancien est absent, invalide ou expiré.
2. Remplacer le panier affiché par l'intégralité du contenu retourné, sans simplement ajouter dans votre interface les places que vous pensiez obtenir.
3. Lire validation, la liste des messages expliquant les éventuels refus ou ajustements, même après ce succès HTTP.

Un refus sur une place n'annule pas nécessairement les autres places acceptées. Un changement de tarif refusé conserve la réservation précédente. Le contenu retourné et les messages, pas le seul statut HTTP, permettent donc d'annoncer à l'utilisateur ce qu'il a effectivement obtenu. Les prix sont recalculés sur les billets présents ; la suite utilise les opérations panier habituelles, notamment articles annexes, validation et paiement.

Ne pas déduire l'action du nombre de places affichées

Le signal à suivre est hasSelection reçu sur OK. Il indique qu'une référence doit être appliquée, même si le choix final ne contient plus aucune place. Par exemple, retirer toutes les places initialement réservées au panier produit une référence pour appliquer ces retraits.

Inversement, sans choix ni réservation initiale à synchroniser, le résultat vaut hasSelection: false : il n'y a pas de référence et vous n'appelez pas ApplySeatSelection.

Référence, échéance et répétition

Une réponse peut être perdue après que StockTicket a déjà modifié le panier. Pour récupérer le résultat sans recommencer l'ajout, conserver la référence pendant l'appel et la réutiliser si sa réponse n'est pas confirmée.

• Traiter la référence comme une valeur opaque ; ne pas la décoder et ne pas la substituer à une clé d'API.
• L'appliquer dans le même contexte authentifié : définition et instance du module de vente et éventuel client externe.
• La première confirmation OK repousse l'échéance unique à maintenant plus la durée configurée par StockTicket (cinq minutes par défaut). Le serveur contrôle cette échéance au démarrage du transfert et avant son enregistrement final. Demander l'application au panier dès réception de la référence : lectures, répétitions d'OK et répétitions de l'appel panier ne prolongent pas sa validité.
• Si la réponse est perdue, répéter la même référence. Ne pas refaire la sélection ni appeler AddEventDate pour les mêmes places.
• Une référence déjà traitée retrouve le panier obtenu et les signalements du premier transfert, sans double ajout. Un autre basketId fourni ensuite ne déplace pas la sélection vers un autre panier.
• Cette répétition reste possible jusqu'à expiration ou révocation de la session. Après expiration, les billets déjà obtenus restent au panier, mais cette référence ne permet plus d'en récupérer le résultat. Ne pas ouvrir une nouvelle sélection pour répéter aveuglément un transfert incertain ; consulter le panier avec le parcours habituel.
• Si le transfert précédent est encore en cours, la demande est refusée temporairement ; une répétition ultérieure peut retrouver le résultat.

Ne pas révoquer la session tant qu'une réponse d'application au panier est incertaine. Un refus d'acquisition de référence produit une erreur de validation pour une référence invalide, expirée, non disponible pour le propriétaire ou déjà en traitement. Le serveur reste l'autorité : une vérification de date côté navigateur ne prouve pas la validité.

Messages du panier et enum à drapeaux

Pour expliquer le résultat à l'utilisateur, afficher le texte message de chaque entrée de validation. Si votre interface doit retrouver le choix concerné, l'entrée peut aussi fournir itemId, paramName et paramValue. Pour les refus SeatSelection, paramName vaut selectionReference et paramValue contient l'adresse et les références tarifaires concernées : sectionId, zoneId, rowId, seatId, priceCategoryId, priceCategoryItemId.

Le champ messageType qualifie le message. Il utilise BasketValidationEntryTypeEnum, une enum de drapeaux : plusieurs qualifications peuvent être présentes ensemble, par exemple « avertissement concernant un paramètre ». Votre code reçoit ces qualifications ; il ne les envoie pas dans la demande d'application. Voici toutes les valeurs nommées :

Les noms peuvent être combinés dans la chaîne JSON, séparés par des virgules, par exemple "Parameter, Warning". Ne pas dépendre de leur ordre ni tester seulement l'égalité à Warning. L'application SeatSelection produit la combinaison Warning | Parameter pour une unité refusée. PriceChanged est un code composé nommé, pas un drapeau élémentaire supplémentaire ; le reconnaître comme tel.

6. Reprise, expiration et abandon

Une coupure de communication n'est pas une expiration ni un abandon. Par exemple, un utilisateur peut perdre le réseau après un ajout accepté : le composant doit retrouver ses choix, pas ouvrir une nouvelle session. Le tableau indique l'action attendue de votre code :

flowchart TD
    A[Incident ou fermeture de l'interface] --> B{Situation}
    B -->|Coupure réseau| C[Le SDK reprend la même session et ses opérations incertaines]
    B -->|Réponse panier perdue| D[Le serveur du module de vente répète la même référence]
    B -->|Délai écoulé| E[Session inutilisable : fermer le composant et informer]
    B -->|Retrait visuel| F[unmount : ferme les ressources, sans Cancel]
    B -->|Abandon explicite du module de vente| G[Le serveur appelle RevokeSession : invalide la délégation]
    B -->|Cancel confirmé par le composant| H[Quitte la sélection, sans application panier]

Laisser le composant reprendre sa connexion

Le fournisseur utilise le SDK pour communiquer avec StockTicket par le protocole SignalR. Ce SDK rétablit sa connexion, relit la session et retrouve les opérations dont la réponse a pu être perdue. Le composant est chargé d'actualiser son affichage et de vous transmettre une éventuelle fin retrouvée.

Votre module de vente n'a donc pas à rejouer les choix ou à ouvrir une session sur chaque coupure : cela perdrait le lien avec les demandes incertaines. Une coupure du composant et une réponse perdue à votre propre appel panier sont deux situations distinctes : seul ce dernier cas demande de répéter ApplySeatSelection avec votre référence conservée.

Comprendre le délai unique

StockTicket fixe une durée unique, cinq minutes par défaut. L'ouverture, la première connexion effective du composant, un ajout créant réellement un nouveau blocage et le premier OK repoussent l'échéance à maintenant plus cette durée. Cela concerne aussi les quantités en placement libre. Les reconnexions, lectures, retraits, changements de tarif, refus et répétitions ne la repoussent pas.

Le même délai couvre session, autorisation, blocages et référence de sélection. Votre code ne programme aucune prolongation et ne remplace jamais le jeton. Le composant reçoit l'échéance actualisée dans les états du SDK. À expiration, la session est définitivement inutilisable et StockTicket restitue les nouveaux blocages ; les réservations initiales et les places déjà transférées au panier restent intactes. La notification n'est pas garantie en cas de coupure réseau : le composant constate aussi l'indisponibilité lors d'une reprise.

Distinguer durée de session, retrait visuel et abandon

Fermer l'interface ou perdre la connexion ne libère pas les blocages à lui seul. Pour un simple retrait visuel, utiliser host.unmount() ; pour abandonner explicitement le parcours, demander sa révocation.

Si vous souhaitez abandonner la session depuis votre module de vente, demander sa révocation. Si c'est l'utilisateur qui actionne Annuler dans le composant, celui-ci demande Cancel à StockTicket puis vous transmet l'événement confirmé. Cancel, révocation et expiration libèrent les blocages provisoires, mais pas les places qui étaient déjà réservées au panier à l'ouverture.

Enfin, ces actions ne reviennent pas sur une application au panier déjà réussie. Pour modifier ensuite le panier, utiliser les opérations panier habituelles ; ne pas révoquer une session en pensant retirer les billets obtenus.

Pour révoquer, votre serveur effectue POST /api/client/v1/SeatSelection/RevokeSession?sessionId=... vers l'API StockTicket, sans corps JSON, avec la même authentification commerciale qu'à l'ouverture. La réponse est 204 sans contenu. Le propriétaire reste celui de l'ouverture : définition et instance du module de vente, avec l'éventuel client externe.

Référence des statuts HTTP

7. Sécurité et déploiement

Votre intégration utilise deux autorisations distinctes : votre serveur conserve l'authentification du module de vente pour les appels API ; le navigateur reçoit uniquement le jeton restreint de la session pour le composant. Les contrôles suivants concernent respectivement votre intégration et son hébergement.

Dans votre code de vente

• Conserver Stk-Api-Key, les en-têtes d'authentification commerciale et tout jeton d'administration sur votre serveur ; ne jamais les transmettre au navigateur. Donner uniquement les paramètres de montage à SeatSelectionHost.
• Utiliser l'URL fournisseur annoncée au catalogue et validée pour votre intégration. Son JavaScript s'exécute dans votre page. Le Shadow DOM, que le fournisseur peut utiliser pour isoler son affichage des styles de la page, n'isole pas ses privilèges.
• Conserver jeton et référence uniquement pour le parcours en cours. Ne pas les recopier dans les logs, les attributs HTML, les URL construites par votre code ou un stockage persistant. Ne pas mettre en cache les réponses de lancement.
• Afficher les messages retournés comme du texte, sans injecter leur contenu dans le HTML de votre page.

8. Vérifications manuelles de l'intégration

Vérifier ces situations dans votre module de vente avec un fournisseur de sélection et une API HTTPS. Le but est de contrôler le parcours visible par l'utilisateur et le panier obtenu, pas uniquement le succès du chargement JavaScript.

1. Capacité activée puis désactivée, représentation associée puis non associée : affichage conditionnel correct et maintien du parcours de vente existant.
2. Fournisseur servi depuis une autre origine : import autorisé, conteneur connecté et aucun jeton dans le HTML ou les diagnostics.
3. Ouverture avec panier : seules ses réservations de la représentation entrent dans la sélection initiale, sans modification immédiate du panier.
4. OK sans référence : pas d'appel panier. OK avec référence, y compris sélection finale vide : synchronisation et récupération du panier retourné.
5. Refus partiels : lecture et affichage de validation après 201, sans déclarer toutes les places acceptées.
6. Réponse d'application perdue : même référence répétée, sans double ajout ni création d'un second panier.
7. Cancel confirmé, retrait visuel et révocation : trois comportements distincts ; aucune suppression implicite des réservations initiales.
8. Coupure réseau et réponse de fin perdue : reprise avec le même jeton avant échéance, sans nouvelle ouverture intempestive. Après expiration, fermeture et nouveau parcours seulement sur décision de l'utilisateur.
9. Import fournisseur refusé, fabrique absente, montage remplacé : codes de montage neutres et absence d'élément tardif inséré.
10. Lecture de ces deux pages dans MkDocs : navigation, liens internes et rendu des schémas Mermaid.
11. Dans l'onglet Réseau du navigateur, aucune requête vers l'API StockTicket pour le catalogue, l'ouverture, l'application au panier ou la révocation, et aucun en-tête Stk-Api-Key. Ces appels partent du serveur du module de vente vers l'adresse configurée de l'API, depuis une IP autorisée ; vérifier aussi ce parcours avec des domaines distincts pour le site de vente et StockTicket.

Ces scénarios restent à exécuter dans votre application. Les exemples ne constituent ni un test de charge ni une preuve de validation navigateur.