Activités et billetterie
Voucher ou billet : vérifier ce qui donne réellement accès
Une confirmation de paiement, un voucher à échanger et un billet scannable ne rendent pas le même service. Le voyageur doit savoir quel document présenter, où, quand et que faire si le contrôle échoue.
Réponse directe
Nommer le document selon son usage réel
La confirmation établit que la commande a été acceptée. Un voucher peut demander un échange ou une validation auprès de l’opérateur. Un billet autorise l’entrée selon les règles annoncées. Ces documents peuvent partager une référence, mais ils ne sont pas interchangeables. Présentez le bon titre, le nombre de personnes couvertes, l’horaire et le lieu exact de contrôle.
L’initiative OCTO vise à standardiser les échanges de produits, disponibilités et réservations d’activités. Une intégration doit néanmoins vérifier avec chaque opérateur comment le titre est émis et contrôlé sur place.
Les champs utiles au voyageur et à l’accueil
| Champ | Usage | Erreur fréquente |
|---|---|---|
| Référence fournisseur | Retrouver le dossier au contrôle | N’afficher qu’une référence revendeur |
| Produit et unité | Identifier visite et participants | Confondre billet adulte et enfant |
| Date et créneau | Vérifier l’accès temporel | Omettre l’heure locale ou le fuseau |
| Point d’entrée | Orienter vers le bon guichet | Indiquer seulement l’adresse générale |
| Mode de validation | Scanner, échange ou liste nominative | Promettre un accès direct à tort |
Gardez les instructions de contrôle proches du titre. Un code graphique sans texte alternatif utile ni référence lisible devient fragile sur un écran cassé, une impression médiocre ou une connexion absente.
Gérer remplacement et annulation
Une modification de créneau ou de participant peut rendre l’ancien billet invalide. Émettez un nouveau titre en indiquant clairement lequel remplace l’autre, puis vérifiez que le système de contrôle connaît le changement. Une annulation doit retirer le droit d’entrée et déclencher le traitement financier associé. Gardez la preuve de l’état final sans exposer inutilement les données du voyageur.
Prévoyez aussi le contrôle hors ligne : quelle version des droits est disponible, combien de temps reste-t-elle valable et comment seront résolus les conflits une fois la connexion rétablie ?
Tester à l’entrée, pas seulement au paiement
- Réserver deux adultes et un enfant sur un créneau presque complet.
- Contrôler les documents reçus sur téléphone et en impression.
- Changer l’horaire et vérifier que l’ancien titre est refusé.
- Simuler un scan impossible et retrouver le dossier par référence.
- Annuler une unité et vérifier le nombre de droits et le remboursement.
Un modèle de titre d’accès et un scénario de contrôle partagé avec l’opérateur, le distributeur et l’équipe d’accueil.
Dossier d’exercice · données fictives
Un document téléchargé ne prouve pas à lui seul le droit d’accès courant
Une activité fictive est confirmée pour deux adultes et un enfant à 10 h. Le départ est ensuite remplacé par 14 h. Le dossier est mis à jour, mais le voyageur garde le fichier de 10 h dans son téléphone. La recette doit suivre état de réservation, personnes et titre effectivement présenté, avec les instructions d’échange ou d’accès propres à la connexion.
- Version de 14 hRéservation
État courant à retrouver dans le dossier.
- Ancien fichier 10 hDocument
Présence d’un code ne démontre pas sa validité actuelle.
- Titre à présenterAccueil
Vérifier personnes, horaire et mode de contrôle.
| Point du dossier | Ce qui est établi | Ce qui reste à vérifier |
|---|---|---|
| Dossier courant | Départ de 14 h confirmé dans le scénario | Référence et personnes concernées |
| Fichier conservé | Départ de 10 h | Identifier la version remplacée |
| Nouveau document | À obtenir ou retrouver selon le parcours | Ne pas le supposer réémis automatiquement |
| Accès | Direct ou après échange selon la règle | Conserver les instructions réelles |
Ce que le rapprochement permet de comprendre
OCTO distingue la réservation retenue temporairement et sa confirmation. Les formats de documents et capacités doivent être vérifiés dans l’intégration utilisée. Le cas décrit la reprise après changement ; il n’affirme pas qu’un code quelconque constitue partout un billet d’entrée directe.
Quatre situations à rejouer
Ouvrir un cas pour lire son résultat et les éléments à retrouver. Les chiffres, horaires et références des situations sont fictifs ; les règles de votre dossier restent à confirmer.
Le PDF est remis depuis l’historique
Le conseiller retrouve facilement l’ancien fichier et le transmet, sans lire sa date ni sa version.
À retrouver ou à transmettre. Rapprocher référence, départ, personnes et consigne du document courant ; signaler explicitement le document remplacé.
Le code est lisible et supposé valide
La lecture visuelle ou technique du code ne renseigne pas nécessairement l’état d’annulation ou de remplacement.
À retrouver ou à transmettre. Vérifier le circuit de contrôle et sa source d’état ; ne pas simuler une admission réelle à partir du seul format.
L’enfant manque sur la nouvelle émission
Le changement d’horaire est correct, mais les personnes couvertes ne correspondent plus au dossier.
À retrouver ou à transmettre. Comparer unités, catégories et participants selon le produit ; garder l’écart avant transmission du titre.
Le document demande un échange sur place
Le message envoyé promet une entrée directe, alors que la consigne exige un échange au point désigné.
À retrouver ou à transmettre. Transmettre titre courant, périmètre, adresse, échange éventuel et support ; vérifier ce que l’accueil doit réellement recevoir.
OCTO — réservation et confirmation · consultée le . Distinction du cycle de réservation ; format et validité du titre dépendent de la connexion. Activité, horaires et documents fictifs.
Observer les refus à l’entrée
Classez les incidents de contrôle par cause : mauvais point d’entrée, date erronée, ancien titre, code illisible, droit absent ou connexion indisponible. Rapprochez chaque incident de la réservation et de sa dernière modification. Une fréquence élevée de codes valides mais inconnus du contrôle suggère un défaut de synchronisation plutôt qu’un problème de présentation du billet.
Retrouver langue et support dans la prestation confirmée
Un voucher doit rester rapprochable de l’option choisie. Une fiche traduite ne garantit pas une prestation dans cette langue, et une langue présente sur le produit peut concerner une autre option. Vérifiez humain, audio ou écrit avant de compléter les informations transmises au voyageur.
Après un changement d’horaire ou d’option, relisez la langue et le support avec la confirmation reçue. Si la preuve ne les indique pas, demandez comment vérifier le service confirmé. Ajouter une mention sur le billet ne modifie pas à lui seul l’engagement du fournisseur. Consultez le Langues des visites : guide humain, audioguide et contenu traduit.
Tester le document présenté à l’accueil après modification
OCTO distingue le socle d’intégration et des capacités optionnelles ; les documents reçus dépendent du fournisseur et des fonctions activées.
Scénario fictif : une visite est déplacée au lendemain alors que l’ancien billet reste dans le téléphone du voyageur. Demandez ce qui change dans la réservation, le titre et la procédure de contrôle. Testez l’ancien document selon le mécanisme autorisé et faites expliquer l’état au personnel d’accueil. Une preuve de paiement n’est pas nécessairement le document permettant l’entrée. Le message client doit indiquer quel titre utiliser et comment retrouver la version correcte.
| Point | Preuve à conserver | Contrôle à effectuer |
|---|---|---|
| Référence | Réservation et titre lié. | Retrouver l’engagement derrière le code présenté. |
| Version | Date, participants et statut. | Comparer titre initial et document modifié. |
| Contrôle | Règle d’admission et recours. | Prévoir un titre illisible ou une connexion absente. |
Validez avec l’accueil le document utilisable, sa version et la reprise. La génération d’un PDF ne démontre pas son acceptation sur place.
Rapprocher ce sujet du dossier suivant
Un voucher de pass urbain peut identifier un droit général sans confirmer chaque visite. Faites rapprocher activation, période applicable et réservations des attractions. Pour transmettre un billet utilisable, conservez aussi les créneaux obtenus et les choix déjà consommés ; la présence du code ne démontre pas à elle seule l’accès à tout le programme.
Pass urbains : activation, visites et réservations de créneaux · Vérifier les preuves de ce dossier
Cas à rapprocher : Listes d’entrée : contrôler les bons droits au bon accès
Le contrôle d’un billet doit être rattaché à la liste et à l’accès concernés. Un document peut porter plusieurs droits, avec des réponses distinctes par séance. Conservez le motif d’un scan non admis et le circuit de reprise au lieu d’assimiler toute absence à une annulation.
Listes d’entrée : contrôler les bons droits au bon accès · Vérifier les preuves de ce dossier
Approfondir le parcours : Validité d’un billet : document, date et créneau à utiliser
Le suivi du billet doit distinguer sa période d’usage des échéances d’une réserve. Une disponibilité et un document sont des objets à rapprocher. Le dossier conserve la version à présenter et les éventuelles étapes de créneau restantes.
Validité d’un billet : document, date et créneau à utiliser · Rapprocher les preuves du parcours
OCTO : disponibilité retenue, expiration et confirmation
La retenue temporaire de capacité et la confirmation de réservation sont des étapes différentes du parcours OCTO.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| availabilityId | Un contrôle de disponibilité fournit la référence nécessaire à la création de la réservation. | Conserver produit, option et disponibilité sélectionnés dans le même contexte. |
| ON_HOLD | La création retient la capacité jusqu’à confirmation ou expiration ; la durée demandée est bornée par le fournisseur ou son prestataire OCTO. | Lire l’échéance retournée au lieu de supposer une durée universelle de retenue. |
| Confirmation | Une réservation retenue peut être confirmée tant qu’elle n’a pas expiré. | Vérifier le statut retourné avant de présenter la prestation comme confirmée. |
| Annulation | Le parcours documente POST /bookings/{uuid}/cancel, distinct d’une suppression HTTP DELETE. | Suivre le contrat de l’opération et ses conditions d’annulation. |
Le standard ne constitue pas un catalogue vendable et ne prouve pas l’activation de toutes les fonctions pour un revendeur.
OCTO — Core Bookings · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
Viator : suivre une confirmation différée jusqu’à son résultat
Le mode de confirmation détermine ce que le client peut considérer comme réservé.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| Trois modes | confirmationType distingue INSTANT, MANUAL et INSTANT_THEN_MANUAL. | Identifier le mode du produit avant de choisir le message de confirmation. |
| Attente limitée | Une demande manuelle non traitée est rejetée après 72 heures ou à l’atteinte de sa limite de réservation, si celle-ci arrive avant. | Ne pas présenter 72 heures comme un délai toujours disponible. |
| Paiement et billet | Le parcours manuel prévoit la facturation après confirmation et le voucher seulement une fois la réservation confirmée. | Distinguer préautorisation, paiement et document disponible, prestation par prestation. |
Périmètre transactionnel Merchant ou Affiliate Full + Booking autorisé ; ne pas confondre cette Partner API avec la Supplier API.
Viator Partner API — Booking confirmation types · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
Hotelbeds Activities : transmettre le bon document après confirmation
Le document remis au voyageur doit reprendre la réservation confirmée et les consignes d’utilisation du billet.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| Source finale | Le guide demande de reprendre les informations du voucher depuis la réponse de réservation. | Ne pas reconstruire le document à partir d’un ancien résultat de recherche. |
| PDF fourni | Pour les produits en intégration directe qui retournent un PDF dans vouchers après confirmation, Hotelbeds demande de transmettre ce PDF sans régénérer un autre voucher. | Identifier le circuit applicable au produit. |
| Consignes | Les commentaires de type CONTRACT_REMARKS donnent notamment les modalités pour obtenir les billets. | Conserver ces consignes ; une référence de réservation seule peut être insuffisante. |
| Deux identités | Le guide distingue providerInformation, pour les coordonnées du prestataire, de supplier, pour les mentions « bookable and payable ». | Distinguer coordonnées opérationnelles et intermédiaire commercial. |
Exigences du circuit Activities documenté. Un voucher ne dispense pas de lire ses conditions d’échange ou d’accès.
Hotelbeds — Activities certification, voucher information · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
Tiqets : retrouver le billet et la langue choisis à la commande
Une référence de commande et un texte traduit ne suffisent pas à prouver que le billet PDF est prêt dans la langue attendue. Relisez séparément l’état de commande et les règles du document.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| Création et traitement | Dans le schéma, new désigne une commande créée mais pas encore confirmée par le distributeur ; pending indique que Tiqets traite sa délivrance. | Conservez l’état reçu ; ne présentez pas ces deux étapes comme un billet déjà délivré. |
| Document disponible | done signifie que les billets PDF sont prêts. tickets_pdf_url vaut null tant que order_status n’est pas done. | Vérifiez l’état et la présence de l’URL avant de transmettre le document au voyageur. |
| Langue du PDF | La langue du voucher dépend de la langue définie lors de la création de commande. Le paramètre lang de la lecture sélectionne le contenu retourné et vaut anglais par défaut. | Ne promettez pas qu’une nouvelle lecture avec lang=fr traduit le PDF d’une commande créée dans une autre langue. |
| Notification ou relecture | La documentation propose callback_url pour les changements d’état ; en polling, elle recommande un espacement progressif ou de cinq à dix minutes, au maximum pendant vingt-quatre heures. | Choisissez un suivi adapté ; n’interprétez pas cette recommandation comme un délai garanti de délivrance. |
Trois informations de langue et de délivrance à conserver
Repères de lecture pour un dossier Tiqets ; aucun billet n’est créé sur cette page.
- À la commande
Conserver la langue transmise lors de la création : elle détermine celle du voucher.
- À la consultation
Relever lang et l’état retourné ; un contenu de réponse en français ne prouve pas la langue du PDF.
- À la remise
Retrouver done, l’URL du PDF et le document correspondant au dossier avant l’envoi au client.
Deux contrôles avant la remise du billet
Dossiers fictifs pour préparer une recette de délivrance.
Le texte est en français, le billet a été créé en anglais
Une commande de démonstration a été créée avec la langue anglaise, puis consultée avec lang=fr.
Langue à la création : en
Lecture : lang=fr
État : doneLecture du cas. Les textes de consultation peuvent être en français alors que le voucher reste lié à la langue initiale. Vérifiez le document avant de promettre sa traduction ; une simple relecture ne change pas ce réglage.
Une commande existe mais le lien PDF est vide
Le distributeur retrouve sa référence et une réponse pending.
order_status : pending
tickets_pdf_url : null
Référence : retrouvéeLecture du cas. Le traitement est encore en cours. Gardez le suivi prévu par notification ou relecture espacée ; n’annoncez pas que le billet est prêt et ne recréez pas la commande uniquement pour obtenir un document.
Périmètre : endpoint Tiqets GET /orders/{orderReferenceId}/tickets. Le schéma utilise cancelled pour une commande auparavant délivrée puis annulée. La langue des contenus de réponse et celle du document sont deux réglages distincts.
Tiqets Distributor API — Retrieve tickets · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
Checkfront : retrouver la signature et son rattachement à la bonne réservation
Un formulaire signé à l’accueil doit aussi être retrouvé dans le dossier concerné. Checkfront décrit deux parcours : rattachement d’un document complété depuis le répertoire public, ou remplissage directement depuis la facture de réservation.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| Répertoire public | Après la signature dans Public Directory, le document peut être attribué à une réservation depuis l’onglet Documents. | Ne présentez pas la seule présence d’une signature dans le répertoire comme un lien déjà vérifié avec la séance du client. |
| Document à sélectionner | La fenêtre Attribute Documents présente le nom du titulaire principal, le nom du document et sa date de signature ; une recherche par nom de client est possible. | Rapprochez ces informations avec la réservation et les participants au lieu de retenir uniquement le premier nom ressemblant. |
| Rattachement à contrôler | La sélection puis l’action Attach rattachent un ou plusieurs documents ; ils deviennent visibles dans l’onglet Documents du dossier. | Relisez le résultat dans la réservation visée avant de marquer le contrôle documentaire comme terminé. |
| Remplissage depuis la facture | Depuis Documents puis Fill Out Document, le formulaire est rempli, signé et soumis avec Submit Document. Ce parcours l’attribue automatiquement à la réservation. | Vérifiez que la soumission a abouti ; l’ouverture du formulaire ou le seul affichage de la signature ne décrit pas toute la procédure. |
De la signature au document retrouvé dans le dossier
Parcours de contrôle proposé ; le rattachement peut être manuel ou automatique selon le point de départ.
- Identifier le parcours
Distinguer le document rempli dans le répertoire public de celui ouvert depuis la facture.
- Vérifier le document
Rapprocher client, document, date et réservation avant une attribution manuelle.
- Relire le résultat
Retrouver le document soumis dans l’onglet Documents de la réservation concernée.
Deux signatures dont le suivi est différent
Scénarios fictifs, sans nom réel de participant ni document de consentement utilisable.
La signature existe mais le dossier ne la montre pas
Un client fictif remplit le formulaire dans Public Directory. L’équipe retrouve sa signature, mais rien n’apparaît encore dans la réservation.
Point de départ : répertoire public
Signature : retrouvée
Onglet Documents du dossier : lien à vérifierLecture du cas. Utilisez le parcours d’attribution prévu, après rapprochement du client, du document et de la réservation. Contrôlez ensuite la présence du document dans ce dossier ; ne terminez pas le suivi au seul constat d’une signature.
Un formulaire ouvert depuis la facture n’a pas été soumis
L’équipe fictive ouvre Fill Out Document depuis la réservation, mais la dernière étape Submit Document n’a pas été réalisée.
Parcours : depuis la facture
Formulaire : ouvert et rempli
Soumission : pas encore effectuéeLecture du cas. Le parcours automatique décrit par Checkfront inclut la soumission. Faites terminer cette étape par le circuit prévu, puis relisez le rattachement dans le dossier au lieu de le déduire de l’ouverture du formulaire.
Périmètre : parcours Checkfront Classic Items et Classic Products décrits dans cette aide, consultée le 23 octobre 2026. Les permissions Waivers & Documents sont nécessaires. Le rattachement technique ne prouve ni validité juridique du contenu signé ni admission du participant à toutes les prestations.
Checkfront — Attributing Waivers & Documents to bookings · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
pretix : une commande en attente d’approbation peut déjà réserver le quota et les sièges
L’approbation d’un tarif réservé à un public particulier s’applique au parcours de commande. Elle agit sur la capacité retenue et sur l’accès au paiement ; ces états doivent rester distincts dans le suivi.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| Approbation avant paiement | Le client peut commander un produit soumis à approbation, mais doit attendre sa validation pour payer. | Retrouvez la décision sur la commande avant d’expliquer au client pourquoi le paiement reste inaccessible. |
| Quota et sièges retenus | La commande en attente réserve le quota et, s’il existe, le plan de salle comme une commande en attente de paiement. | Comptez cette capacité retenue sans l’assimiler à des recettes encaissées ni à des places encore libres. |
| Commande avec plusieurs produits | Un seul produit soumis à approbation entraîne l’approbation de toute la commande. Un refus peut nécessiter de la scinder. | Testez un panier comprenant tarif standard et tarif à justifier ; ne supposez pas que le premier sera traité indépendamment. |
| Après la décision | Après approbation, le client reçoit un courriel lui permettant de poursuivre le paiement. Une commande entièrement gratuite ne demande pas cette seconde étape. | Vérifiez le résultat adapté au prix de la commande : approbation et encaissement restent deux contrôles différents pour une commande payante. |
Capacité retenue, décision et paiement
Parcours simplifié d’une commande payante soumise à approbation dans pretix.
- Commande à examiner
Le quota et les sièges concernés sont retenus pendant l’attente de décision.
- Décision d’approbation
L’équipe vérifie le tarif demandé et approuve ou refuse la commande selon la procédure prévue.
- Client invité à payer
Après approbation d’une commande payante, le courriel permet au client de poursuivre le paiement.
- Règlement à retrouver
Le suivi vérifie le paiement obtenu et son rattachement à la commande, séparément de la décision d’approbation.
Deux commandes à examiner avant de lire les disponibilités
Places, produits et commandes fictifs pour tester la procédure d’approbation.
Des sièges retenus sont comptés comme encore libres
Une commande fictive demande deux places avec un tarif soumis à validation. La décision est en attente et le paiement n’a pas commencé.
Places demandées : 2
Approbation : en attente
Paiement : pas encore accessibleLecture du cas. Les deux places peuvent déjà être retenues par la commande en attente. Ne les ajoutez pas aux places libres au seul motif que la recette n’est pas encaissée. Retrouvez la commande et son état dans le contrôle de capacité.
Un tarif standard partage la commande d’un tarif à justifier
Un panier fictif contient une place au tarif standard et une place avec réduction nécessitant une approbation.
Produit A : tarif standard
Produit B : approbation requise
Commande : panier communLecture du cas. Le réglage d’approbation concerne toute cette commande. Préparez le contrôle du tarif à justifier et, en cas de refus, le traitement éventuel des produits séparément plutôt que de considérer la place standard comme déjà payée ou traitée à part.
Guide officiel pretix consulté le 23 octobre 2026. Préparez les justificatifs du tarif, la décision d’approbation, les quantités retenues et le résultat du paiement. Pour un panier mixte, vérifiez le traitement de chaque produit avant de modifier la commande.
pretix — Restricted audience, Order approvals · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
Regiondo : distinguer demande, réservation et paiement en attente
Le libellé d’un état doit rester attaché à son objet. Les huit états ci-dessous décrivent le tableau de bord Regiondo ; ils ne forment pas ici un schéma universel de transitions.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| Inquiry | Le client adresse une demande individuelle depuis le bouton de contact. | Retrouver la demande et la réponse de l’opérateur avant de parler de confirmation. |
| Pre-approved | L’opérateur répond avec une proposition ; le client doit encore décider de l’accepter. | Conserver la proposition et la preuve d’accord séparément. |
| Action required | Le client attend une confirmation ; l’article indique une période de six jours. | Attribuer le suivi et retrouver l’échéance du dossier, sans appliquer ce délai à toutes les plateformes. |
| Reservation | Une entrée avec l’état Reservation peut être créée via POS/Add Booking ; elle peut être supprimée ou transformée en réservation dans le parcours décrit. | Ne pas présenter cet état préparatoire comme Confirmed. |
| Confirmed | La demande est confirmée ; l’aide distingue aussi des variantes avec bon et bon utilisé. | Relire produit, date, participants et variante de statut ; rapprocher séparément le paiement. |
| Declined | L’opérateur a refusé la demande du client. | Conserver le refus et l’information destinée au client sans inventer une prestation confirmée. |
| Expired | L’article décrit une confirmation non effectuée dans les six jours ; une nouvelle demande est alors nécessaire. | Distinguer cette expiration de demande de la date d’expiration d’un bon. |
| Canceled | Une réservation confirmée a été annulée ou une demande a été retirée ; plusieurs variantes sont distinguées. | Retrouver le dossier concerné et le traitement financier ; le libellé seul ne prouve pas un remboursement. |
Trois objets à rapprocher, trois preuves à conserver
Repères de lecture éditoriaux, sans transition automatique supposée entre ces objets.
- Réservation
Produit, créneau, participants, proposition et confirmation attendue ou retrouvée.
- Bon
Code, valeur restante, validité et statut propres au bon.
- Paiement
Opération, montant, devise et résultat ; un changement d’état de réservation ne suffit pas à prouver un mouvement de fonds.
Quatre états dont la portée doit rester explicite
Dossiers fictifs ; aucune demande, confirmation ou opération de paiement n’est exécutée.
Une proposition de 14 h remplace la demande de 10 h
Le client fictif n’a pas encore accepté l’alternative.
Demande initiale : 10 h
Proposition : 14 h
Statut : Pre-approved
Réponse du client : absenteLecture du cas. Garder 14 h comme une proposition en attente. La préapprobation de l’opérateur ne remplace pas l’accord du client ni la confirmation finale.
Une entrée POS est prise pour une réservation confirmée
L’équipe fictive retrouve une ligne Reservation créée pour préparer le dossier.
Parcours : POS/Add Booking
État : Reservation
Transformation en réservation : non vérifiéeLecture du cas. Retrouver la suite du parcours avant de remettre un document comme confirmation de prestation. Le mot Reservation ne se substitue pas à l’état Confirmed dans cet article.
Une tentative abandonnée pendant le paiement apparaît en attente
La ligne fictive se trouve dans Pending bookings avec un motif de paiement interrompu.
Rubrique : Pending bookings
Motif : canceled or timed out during payment
Réservation Confirmed antérieure : non retrouvéeLecture du cas. Ne pas décrire automatiquement une prestation confirmée puis annulée. Vérifier le dossier et les transactions concernées ; une tentative de paiement interrompue ne démontre pas à elle seule tous les mouvements financiers.
Expired est lu comme la fin de validité d’un bon
Le mot Expired figure dans la liste de réservations et non dans Voucher Overview.
Objet : demande de réservation
État : Expired
Code et date de validité d’un bon : non fournisLecture du cas. Dans le parcours de l’article, il s’agit de l’expiration de la demande non confirmée dans les six jours. La validité d’un bon se retrouve sur cet autre objet ; ne pas la déduire du seul mot identique.
Portée : aide du tableau de bord Regiondo, consultée le 1er novembre 2026. Pending bookings possède aussi des motifs liés au paiement ; ne pas les confondre avec une prestation confirmée puis annulée. Aucun état courant d’un vrai dossier n’est vérifié.
Regiondo — Available booking statuses · mise à jour par la source le 20/04/2026 · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
Regiondo — confirmation manuelle · consultée le 01/11/2026
Regiondo — Pending bookings · consultée le 01/11/2026
Sources et périmètre des faits documentés
La date de consultation figure avec chaque référence. Les méthodes d’essai et recommandations de ce guide sont éditoriales ; les conditions d’accès et d’usage se vérifient dans la documentation actuelle.
- OCTO : opérations de base et capacités optionnelles : Socle OCTO et capacités optionnelles ; le format et la validité du titre d’accès restent à confirmer pour la connexion. (consultée le )
- OCTO — réservation et confirmation : Distinction du cycle de réservation ; format et validité du titre dépendent de la connexion. Activité, horaires et documents fictifs. (consultée le )
- Viator Partner API — Booking confirmation types : Périmètre transactionnel Merchant ou Affiliate Full + Booking autorisé ; ne pas confondre cette Partner API avec la Supplier API. (consultée le )
- Hotelbeds — Activities certification, voucher information : Exigences du circuit Activities documenté. Un voucher ne dispense pas de lire ses conditions d’échange ou d’accès. (consultée le )
- Tiqets Distributor API — Retrieve tickets : Périmètre : endpoint Tiqets GET /orders/{orderReferenceId}/tickets. Le schéma utilise cancelled pour une commande auparavant délivrée puis annulée. La langue des contenus de réponse et celle du document sont deux réglages distincts. (consultée le )
- Checkfront — Attributing Waivers & Documents to bookings : Périmètre : parcours Checkfront Classic Items et Classic Products décrits dans cette aide, consultée le 23 octobre 2026. Les permissions Waivers & Documents sont nécessaires. Le rattachement technique ne prouve ni validité juridique du contenu signé ni admission du participant à toutes les prestations. (consultée le )
- pretix — Restricted audience, Order approvals : Guide officiel pretix consulté le 23 octobre 2026. Préparez les justificatifs du tarif, la décision d’approbation, les quantités retenues et le résultat du paiement. Pour un panier mixte, vérifiez le traitement de chaque produit avant de modifier la commande. (consultée le )
- Regiondo — Available booking statuses : Portée : aide du tableau de bord Regiondo, consultée le 1er novembre 2026. Pending bookings possède aussi des motifs liés au paiement ; ne pas les confondre avec une prestation confirmée puis annulée. Aucun état courant d’un vrai dossier n’est vérifié. (consultée le )
Questions fréquentes
Questions utiles avant de décider
Le courriel de confirmation suffit-il pour entrer ?
Cela dépend de l’opérateur. La page de vente et le document doivent préciser si le courriel, un voucher à échanger ou un billet individuel est requis.
Que faire lorsque le code ne se scanne pas ?
Prévoir une recherche manuelle à partir de la référence et un canal d’assistance, sans accepter automatiquement un simple reçu de paiement.
Faut-il un billet par participant ?
Pas toujours. Le titre peut couvrir un groupe ou plusieurs unités ; son périmètre doit être clair pour le personnel d’accueil et pour les voyageurs.
Que faire si la confirmation ne précise pas le guidage ?
Demandez une preuve reliant option, départ, langue et support. Ne reconstituez pas ces caractéristiques depuis le titre traduit du produit.
Un reçu de paiement permet-il toujours l’entrée ?
Le prestataire détermine le titre et la procédure acceptés. Vérifiez le document explicitement requis pour la prestation.
Faut-il recréer un voucher lorsque Hotelbeds Activities fournit déjà un PDF ?
Pour les produits en intégration directe décrits dans son guide, Hotelbeds demande de transmettre le PDF retourné dans vouchers après confirmation. Ce n’est pas une règle universelle pour tous ses produits : identifiez le circuit applicable et conservez les consignes d’échange du document.
Relire une commande Tiqets avec lang=fr change-t-il la langue du billet PDF ?
Non. La langue du voucher est fixée à la création de commande. Le paramètre lang de la lecture concerne les contenus de réponse. Vérifiez aussi que l’état est done avant de transmettre le lien du PDF.
