Prix et transparence
Prix total d’un voyage : du résultat de recherche au montant réellement dû
Un prix attractif dans la recherche n’aide pas le voyageur s’il change sans explication à la confirmation. Le prix total doit relier prestations, options, taxes, devises et échéances de paiement.
Réponse directe
Construisez le prix du point de vue de la personne qui paie
Le moteur peut manipuler un tarif net, une commission, des taxes locales, un supplément bagage et un acompte. Le voyageur, lui, doit comprendre le montant de son voyage et ce qui reste à régler. Le prix affiché sur une carte de résultat doit être cohérent avec le détail présenté avant confirmation. Lorsqu’une somme se paie à l’établissement ou au prestataire, indiquez cette échéance distinctement.
Établissez une nomenclature commune : base, taxes comprises, taxes à payer sur place, frais de service, options choisies, remise et total. Une ligne doit préciser son bénéficiaire, sa devise et son caractère obligatoire ou facultatif. Ce modèle aide autant la comparaison des offres que le service après-vente.
Contrôlez les montants à chaque étape du parcours
| Étape | Prix à vérifier | Question utile |
|---|---|---|
| Recherche | Prix comparable pour une même occupation et les mêmes dates | Un élément obligatoire manque-t-il au montant mis en avant ? |
| Détail | Prestations, options, conditions et sommes dues sur place | Le voyageur peut-il distinguer inclus et supplément ? |
| Confirmation | Dernier prix accepté avant paiement ou émission | Un changement depuis la recherche est-il expliqué ? |
| Paiement | Montant, devise, échéance et éventuels frais de règlement | La transaction correspond-elle au dossier confirmé ? |
| Après-vente | Différence de prix, avoir ou remboursement selon le changement | Peut-on retrouver la version du prix acceptée ? |
Une capture d’écran isolée ne suffit pas à diagnostiquer un écart. Conservez les références d’offre, les dates de calcul, les règles reçues du fournisseur et la version présentée au client.
Rejouer un prix payable en plusieurs endroits
Exemple fictif dans une seule devise : deux nuits à 100 €, un service obligatoire de 20 € et une taxe connue de 15 € à régler à l’hébergement représentent 235 € au total. Si 220 € sont encaissés en ligne, les 15 € restants doivent rester visibles avec leur bénéficiaire. Le montant du paiement en ligne et le prix total du séjour répondent à deux questions distinctes.
| Changement | Contrôle |
|---|---|
| Ajout d’un enfant | Recalculer occupation, repas et règles de taxe ; conserver les âges utilisés sans supposer une règle universelle. |
| Option facultative à 30 € | Montrer le total choisi à 265 € et distinguer l’option des frais obligatoires. |
| Offre expirée | Redemander le prix, expliquer l’écart et obtenir une nouvelle validation avant engagement. |
| Annulation partielle | Rapprocher le nouveau prix, les frais applicables et les montants déjà encaissés, sans assimiler toute baisse de prix à un remboursement exécuté. |
Les montants et la taxe sont inventés pour l’exercice ; aucune règle locale ni aucun tarif fournisseur n’en est déduit. Conservez l’offre, son horodatage, les conditions acceptées et le détail des sommes dues à chaque acteur.
Séparer prix de l’offre, devise d’affichage et devise de règlement
Un fournisseur peut transmettre un montant dans une devise, le site l’afficher dans une autre et le paiement être réalisé dans une troisième configuration contractuelle. Stockez le montant et la devise d’origine ainsi que le taux et le moment de conversion lorsqu’une conversion est effectivement appliquée. Un taux indicatif dans la recherche ne doit pas être présenté comme un débit garanti.
Vérifiez aussi le remboursement : son montant peut être exprimé dans la devise de la transaction initiale alors que le voyageur consulte son compte dans une autre devise. Expliquez ce que votre organisation contrôle et ce qui dépend du prestataire de paiement ou de la banque, selon les conditions applicables.
Mettre le prix sous contrôle avant d’élargir la distribution
Constituez un échantillon de dossiers avec tarifs simples, remises, taxes, options, annulations et plusieurs devises. Rejouez-les après chaque changement de fournisseur ou de règle. Suivez le nombre de confirmations dont le montant diffère du dernier prix accepté, les erreurs de taxe, les remboursements non rapprochés et les réclamations liées à une somme due sur place.
La comparaison de fournisseurs gagne à intégrer le prix complet et le coût opérationnel. Le guide sur les commissions traite la marge du vendeur ; celui sur le rapprochement suit les transactions après l’achat. Consultez aussi les définitions de prix total et de version de prix.
Rapprocher le prix présenté du programme accepté
Pour les forfaits, la DGCCRF décrit un prix total incluant taxes et autres coûts supplémentaires.
Scénario fictif : le panier comprend un séjour, une option choisie et un frais à payer sur place. Décomposez montant encaissé, montant connu restant et élément encore à confirmer. Reliez chaque ligne à son unité : personne, chambre, nuit ou dossier. Faites tester la suppression d’une option et le changement d’occupation. L’affichage final et le document contractuel doivent expliquer le même programme et les mêmes montants selon la règle applicable.
| Point | Preuve à conserver | Contrôle à effectuer |
|---|---|---|
| Assiette | Quantité, unité, devise et base. | Recalculer une ligne après changement d’occupation. |
| Inclusion | Obligatoire, choisi ou restant à payer. | Distinguer paiement immédiat et engagement total. |
| Accord | Version et détail remis au client. | Rapprocher écran final et pièces. |
Expliquez ce que comprend le montant au moment de l’accord. N’utilisez pas une règle de forfait pour qualifier sans examen toutes les prestations isolées.
Rapprocher ce sujet du dossier suivant
Pour une croisière, la construction du prix total demande de distinguer services compris, options choisies et points encore ouverts. Une prestation visible sur le navire peut avoir un prix propre ou une disponibilité limitée. Rapprochez chaque montant de l’offre et des personnes concernées avant de présenter la confirmation.
Croisière : distinguer prestations incluses et suppléments · Vérifier les preuves de ce dossier
Cas à rapprocher : Surclassement de chambre : offre, disponibilité et accord
Le prix total doit rendre lisible la différence d’un surclassement et la période à laquelle elle s’applique. Rapprochez proposition, accord et document final, puis vérifiez le résultat d’exploitation. Une charge ajoutée ne résout pas une catégorie encore non confirmée.
Surclassement de chambre : offre, disponibilité et accord · Vérifier les preuves de ce dossier
Approfondir le parcours : Frais de ménage : montant, unité et condition dans le séjour
Le contrôle du prix total doit expliquer chaque multiplication. Un frais par séjour, un coût par nuit et une charge conditionnelle suivent des conventions distinctes. Conservez leur composition pour qu’un changement de dates puisse être rapproché sans correction opaque du montant final.
Frais de ménage : montant, unité et condition dans le séjour · Rapprocher les preuves du parcours
Approfondir le parcours : Remises combinées : assiette, ordre de calcul et total accepté
Le contrôle du prix total doit montrer les étapes des remises combinées. Un montant fixe et un pourcentage peuvent dépendre de l’ordre retenu. La confirmation garde le calcul et la règle de cumul propres au choix accepté.
Remises combinées : assiette, ordre de calcul et total accepté · Rapprocher les preuves du parcours
Demand API 3.2 : migrer les champs de prix et les filtres
Le guide de migration 3.2 décrit des changements de structure. Une réponse qui reste un JSON valide peut donc nécessiter un nouveau mapping de champs.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| Prix affiché | Le guide demande price.display à la place de price.book. | Identifier la version de la réponse avant d’interpréter le champ manquant comme un prix absent. |
| Charges | price.charges remplace extra_charges dans la structure décrite ; les indicateurs included_in.display et chargeable_online distinguent affichage et encaissement. | Ne pas déduire le lieu de paiement du seul classement d’une charge dans le prix affiché. |
| Filtres | Des filtres précédemment placés à la racine sont regroupés sous filters. | Comparer le corps de requête avant et après migration ; une valeur bien nommée au mauvais niveau ne filtre pas nécessairement les résultats. |
Cette correspondance est attachée au guide de migration 3.2. Elle ne doit pas être transposée sans vérification à une autre version ou à tous les endpoints Orders.
Booking.com — migration 3.2, recherche d’hébergements · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
Hotelbeds : relire un tarif sans mélanger les opérations
Les bonnes pratiques précisent quand recontrôler le tarif et comment conserver sa référence.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| Référence opaque | rateKey doit être recopié entre opérations, sans interprétation de sa structure interne. | Ne pas extraire dates ou occupation en découpant cette chaîne. |
| Recontrôle ciblé | CheckRates est requis pour RECHECK ; pour BOOKABLE, il peut être utilisé pour une information complémentaire telle que RateComments. | Ne pas recontrôler systématiquement chaque résultat de recherche. |
| Séquence | Le guide recommande un seul rateKey par CheckRates et interdit de lancer CheckRates en même temps que la réservation. | Analyser la réponse du recontrôle avant la demande de confirmation. |
| Attente de réponse | Le délai d’attente de confirmation doit être réglé à au moins 60 secondes. | Prévoir cette attente dans le parcours et distinguer délai dépassé et réservation refusée. |
| Recontrôle de plusieurs tarifs | Les bonnes pratiques demandent de ne pas mélanger des rateKeys RECHECK et BOOKABLE dans une même opération CheckRates ; un seul rateKey par recontrôle est recommandé. | Conserver une réponse identifiable par tarif, sans transformer un échec de lot en refus de toutes les offres du séjour. |
| Origine du mapping hôtelier | Hotelbeds demande de ne pas constituer le mapping hôtelier depuis l’environnement d’évaluation ou de préproduction. | Identifier l’environnement et la source du référentiel avant d’utiliser les correspondances dans un projet réel. |
Du tarif sélectionné au résultat de réservation
Séquence documentaire de Hotel Booking API ; ce schéma ne déclenche aucune opération.
- Identifier le tarif
Conserver rateType, rateKey et les conditions de l’offre sélectionnée sans découper la référence.
- Recontrôler si nécessaire
Pour RECHECK, effectuer le recontrôle avant la réservation. Pour BOOKABLE, le guide réserve ce recontrôle aux besoins d’informations complémentaires.
- Analyser avant de confirmer
Si un CheckRates est nécessaire, examiner sa réponse avant de passer à la confirmation. Ne pas lancer les deux opérations en parallèle.
- Lire le résultat de réservation
Distinguer l’offre relue et la réservation confirmée ; conserver le résultat pour les documents et le suivi.
Six situations à comparer au parcours documenté
Scénarios fictifs, références inventées et actions à examiner ; aucune requête ni réservation réelle.
Un tarif BOOKABLE possède déjà toutes les informations nécessaires
L’offre fictive est sélectionnée et aucune information complémentaire n’est recherchée.
rateType : BOOKABLE
Information complémentaire : non nécessaire
CheckRates systématique envisagé : ouiLecture du cas. Les bonnes pratiques ne demandent pas de recontrôler chaque tarif BOOKABLE. Ne pas transformer ce recontrôle en passage universel. L’offre ne devient une réservation confirmée qu’après le résultat de la réservation.
Un tarif RECHECK est envoyé directement à la confirmation
Le parcours fictif saute l’étape prévue pour actualiser le tarif sélectionné.
rateType : RECHECK
CheckRates : non effectué
Confirmation : envisagéeLecture du cas. Le parcours documenté demande le recontrôle de ce tarif. Examiner sa réponse et les conditions actualisées avant la confirmation ; le résultat initial ne remplace pas cette lecture.
Deux catégories de tarifs sont regroupées dans un même recontrôle
Une seule opération fictive réunit un tarif RECHECK et un tarif BOOKABLE.
Référence fictive A : RECHECK
Référence fictive B : BOOKABLE
Un seul lot CheckRates : envisagéLecture du cas. Le guide demande de ne pas mélanger ces deux types dans une même opération et recommande un seul rateKey par recontrôle. Limiter le recontrôle à l’offre pour laquelle il est nécessaire et garder une réponse identifiable.
Recontrôle et réservation sont lancés au même instant
Le programme fictif cherche à raccourcir le parcours en attendant les deux résultats en parallèle.
CheckRates nécessaire : oui
Analyse de sa réponse : pas encore faite
Réservation en parallèle : envisagéeLecture du cas. Le guide exclut cette simultanéité. Examiner d’abord la réponse du recontrôle ; un résultat de réservation ne doit pas être supposé à partir du seul départ des deux demandes.
Une référence de tarif est découpée pour reconstituer les dates
Une référence inventée contient des caractères qui ressemblent à des éléments du séjour.
rateKey fictif : rk_exemple_A
Structure interne supposée stable : non démontrée
Dates : à retrouver dans les champs du dossierLecture du cas. Conserver la référence comme une valeur opaque et la recopier entre les opérations prévues. Sa structure peut changer ; lire les dates et l’occupation dans leurs données propres.
Un mapping réel est bâti à partir du seul catalogue de préproduction
L’équipe fictive veut reprendre dans le projet les correspondances d’hôtels observées pendant son évaluation.
Source du référentiel : préproduction
Usage visé : projet réel
Concordance avec le référentiel autorisé : à établirLecture du cas. Hotelbeds demande de ne pas établir le mapping hôtelier dans cet environnement. Identifier la source et l’environnement appropriés, puis faire confirmer les correspondances ; la réussite d’un essai ne suffit pas à rendre ces références utilisables dans un autre périmètre.
Bonnes pratiques Hotel Booking API consultées le 31 octobre 2026. Les scénarios sont des lectures éditoriales, sans appel fournisseur. Un recontrôle terminé ne constitue pas une confirmation de réservation et le délai de 60 secondes n’est pas une promesse de réponse au client.
Hotelbeds — Hotel Booking API, Best practices · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
Booking.com Demand : un frais exclu du prix affiché peut rester à payer
Pour expliquer un prix d’hôtel, séparez le total du séjour, les frais encore indéterminés et ce qui sera encaissé en ligne. Un seul indicateur « inclus » ne décrit pas ces trois informations.
| Point documenté | Ce que la source précise | Conséquence pour votre contrôle |
|---|---|---|
| Prix affiché | included et excluded décrivent la position des frais par rapport au prix book ; ils ne désignent pas directement le bénéficiaire du paiement. | Ne traduisez pas excluded par « facultatif » ou « non dû ». |
| Avant confirmation | Dans /orders/preview et /orders/create, les frais obligatoires calculables sont regroupés dans non_conditional et inclus dans total. | Ne rajoutez pas ces lignes une seconde fois au total de réservation. |
| Montant inconnu | Avec le mode incalculable, total_amount vaut null et le frais n’entre pas dans total. | Signalez ce montant restant à préciser ; null ne signifie pas gratuit. |
| Encaissement | Le champ chargeable_online précise si la ligne peut être payée en ligne ; les frais conditionnels restent distincts. | Rapprochez les modalités de paiement du dossier au lieu de déduire « payé en ligne » du seul total. |
Modèle Demand API consulté le 22 octobre 2026. Les montants et conditions restent ceux du produit réservé ; cette lecture ne fixe aucun barème fiscal local.
Booking.com Demand — calcul et conditions des frais supplémentaires · consultée le . Les contrôles proposés sont une lecture éditoriale de cette référence.
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.
- DGCCRF : voyages et séjours à forfait, 16 mars 2026 : Information officielle française sur le prix total d’un forfait ; vérifier le montage et les règles du pays concerné. (consultée le )
- Booking.com — migration 3.2, recherche d’hébergements : Cette correspondance est attachée au guide de migration 3.2. Elle ne doit pas être transposée sans vérification à une autre version ou à tous les endpoints Orders. (consultée le )
- Hotelbeds — Hotel Booking API, Best practices : Bonnes pratiques Hotel Booking API consultées le 31 octobre 2026. Les scénarios sont des lectures éditoriales, sans appel fournisseur. Un recontrôle terminé ne constitue pas une confirmation de réservation et le délai de 60 secondes n’est pas une promesse de réponse au client. (consultée le )
- Booking.com Demand — calcul et conditions des frais supplémentaires : Modèle Demand API consulté le 22 octobre 2026. Les montants et conditions restent ceux du produit réservé ; cette lecture ne fixe aucun barème fiscal local. (consultée le )
Questions fréquentes
Questions utiles avant de décider
Quel montant faut-il comparer entre deux offres ?
Comparez le montant réellement dû pour le même voyageur et les mêmes prestations : taxes, frais et options nécessaires inclus, en distinguant ce qui se paie maintenant et sur place.
Pourquoi le prix change-t-il entre recherche et paiement ?
Disponibilité, tarif fournisseur, sélection des options, devise ou règle de calcul peuvent changer. Vérifiez le prix à la confirmation et expliquez l’écart avant tout engagement du client.
Un paiement en plusieurs fois change-t-il le prix du voyage ?
Le calendrier et les frais éventuels doivent être présentés séparément du contenu du voyage. Vérifiez le montant total dû dans les conditions du moyen de paiement proposé.
Comment tester un remboursement partiel ?
Repartez de la version du prix acceptée, identifiez la prestation modifiée, les frais applicables et les transactions déjà effectuées. Le solde doit se rapprocher du dossier et des justificatifs.
Le montant encaissé est-il toujours le coût total ?
Il peut rester des montants prévus à payer plus tard ou sur place. Identifiez leur nature, leur base et leur statut.
Tableau de travail
Comparer un même périmètre de prix
Proposition de revue éditoriale ; cocher un point ne valide ni un fournisseur ni une réservation.
| Point | Pièce à rapprocher | Suite à préparer | Votre revue |
|---|---|---|---|
| Base | Dates, voyageurs, option et devise affichés | Rapprocher un produit identique entre les étapes. | |
| Compléments | Lignes incluses, suppléments et paiements sur place | Faire confirmer chaque ligne encore inexpliquée. | |
| Version | Récapitulatif accepté et montant demandé | Traiter l’écart avant de présenter le prix comme définitif. |
0 / 3 points marqués comme examinés.
Les marques restent dans cet onglet et ne sont ni envoyées ni enregistrées par ce module.
