Paiements voyage B2B : PSP, change et rapprochement

Faits, limites et références (1)

Documenté : Les webhooks Payouts distinguent événements du lot et des paiements individuels ; les événements de lot ne contiennent pas les données de chaque élément.

Limite : Le succès ou l’échec du lot doit être rapproché des états individuels avant de clôturer la comptabilité.

À demander : Comment retrouver et reprendre uniquement les règlements fournisseurs non aboutis ?

Documentation principale · consultée le 01/10/2026

Faits, limites et références (1)

Documenté : Une notification contient une signature et un payload à analyser ; elle représente un instantané de l’objet concerné et peut arriver hors ordre chronologique.

Limite : Les types de notifications accessibles dépendent de l’opération ; ne pas supposer un événement identique pour tous les paiements.

À demander : Quels événements permettent de rapprocher nos paiements et comment traitons-nous les retards ?

Documentation principale · consultée le 02/10/2026

Faits, limites et références (1)

Documenté : La documentation des webhooks de remboursement distingue notamment queued, pending, processing, failed et refunded. Les notifications portent leur propre identifiant et la référence du paiement associé.

Limite : Référence Refunds API ; vérifier les données et états du paiement concerné, sans traiter une demande comme une restitution déjà aboutie.

À demander : Quel événement permet de passer d’un remboursement attendu à un résultat réellement retrouvé ?

Documentation principale · consultée le 18/10/2026

Contrôles proposés pour ce périmètre

Objets

À réunir : Cas fictif : paiement P6 de 400 € et deux restitutions R1 et R2. Rapprocher chaque remboursement de P6 sans confondre son état avec celui du paiement initial.

Montants

À réunir : R1 de 80 € refunded ; R2 de 40 € pending dans le cas. Retrouver 80 € aboutis et 40 € encore ouverts ; le montant conservé reste provisoirement de 320 €.

Message

À réunir : Confirmation globale de 120 € préparée alors que R2 attend. Corriger le message pour distinguer résultat connu et suite attendue, avec sa référence.

Reprise

À réunir : Notification reçue deux fois ou état reçu tardivement. Relire le remboursement pertinent et ne pas créer une nouvelle restitution depuis la seule répétition du message.

Faits, limites et références (1)

Limite : Une fonction présentée pour le Canada ne démontre pas sa disponibilité sur un contrat français ni sur toutes les devises.

À demander : Quels moyens, pays, comptes et états d’opération sont ouverts pour notre activité voyage ?

Documentation principale · consultée le 07/10/2026

Faits, limites et références (1)

Limite : La couverture d’un réseau ne démontre pas chaque combinaison pays, entité, devise et opération. Qualifier séparément l’encaissement client, le règlement fournisseur et le remboursement.

À demander : Quels moyens et états sont exposés pour chaque flux, et quelle référence permet de rapprocher la réservation du mouvement financier ?

Documentation principale · consultée le 08/10/2026

Faits, limites et références (1)

Limite : Les méthodes et contrats réellement disponibles doivent être vérifiés pour l’entité marchande et le pays visés. La couverture d’une gamme ne décrit pas à elle seule les devises et remboursements du compte.

À demander : Quels moyens seront activés, par quelle entité, avec quelles références pour rapprocher paiement, remboursement et règlement ?

Documentation principale · consultée le 08/10/2026

Faits, limites et références (1)

Limite : Une couverture commerciale n’établit pas toutes les combinaisons pays, devise, moyen, bénéficiaire et opération de remboursement.

À demander : Quels flux et moyens sont ouverts pour chaque marché, et quelles références relient règlement et dossier voyage ?

Documentation principale · consultée le 07/10/2026

Faits, limites et références (1)

Documenté : L’API Transfers documente request_id pour reconnaître une demande de création et rechercher un transfert dont la réponse est incertaine. Elle distingue aussi devises, montants et frais du mouvement.

Limite : Contrat de l’opération citée ; période de reconnaissance, états et montant reçu dépendent des règles documentées et du transfert concerné.

À demander : Comment retrouver une instruction de transfert avant d’en créer une autre lorsque sa réponse a été perdue ?

Documentation principale · consultée le 18/10/2026

Contrôles proposés pour ce périmètre

Intention

À réunir : Cas fictif : transfert fournisseur T8 avec request_id Q8. Conserver références et paramètres du mouvement ; une réponse absente ne prouve pas l’absence d’instruction.

Recherche

À réunir : Demande Q8 envoyée puis délai réseau dépassé. Demander la recherche du transfert par son identifiant selon le contrat avant une nouvelle création.

Montant

À réunir : Instruction de 1 000 €, frais fictifs de 12 € à la charge du bénéficiaire. Rapprocher 988 € attendus dans ces hypothèses, en gardant devise et règle de frais explicites.

Clôture

À réunir : État du transfert et pièce de rapprochement du bénéficiaire. Distinguer instruction acceptée, mouvement exécuté et somme reçue ; attribuer tout écart restant.

Faits, limites et références (1)

Documenté : Les guides distinguent plusieurs intégrations, dont paiements d’entreprise et produits financiers intégrés.

Limite : Pays, entités éligibles et responsabilités varient selon le modèle ; une capacité ne vaut pas disponibilité universelle.

À demander : Qui détient les fonds et quels contrôles précèdent le transfert fournisseur sur nos marchés ?

Documentation principale · consultée le 01/10/2026

Faits, limites et références (1)

Limite : Les services et conditions de change dépendent du pays, de l’offre et du quota ; un compte multidevise n’établit pas une règle de remboursement identique partout.

À demander : Quelle offre et quelle entité couvrent encaissement, change et rapprochement dans nos marchés ?

Documentation principale · consultée le 07/10/2026

Faits, limites et références (1)

Limite : L’existence d’une API n’établit pas l’éligibilité de votre entité ou de votre activité voyage. Séparez le rôle de l’éditeur, celui du marchand et les conditions de traitement des fonds.

À demander : Qui contractualise avec chaque marchand et quels résultats seront disponibles pour encaissement, remboursement, contestation et règlement ?

Documentation principale · consultée le 08/10/2026

Faits, limites et références (1)

Limite : La couverture commerciale ne confirme pas chaque combinaison pays, entité, moyen et remboursement ; les états et règlements doivent être qualifiés par flux.

À demander : Quels moyens sont activés pour notre entité et comment paiements, rejets et remboursements restent-ils rapprochés avec la réservation ?

Documentation principale · consultée le 08/10/2026

Faits, limites et références (1)

Limite : L’activation d’un moyen ne démontre pas les règles de remboursement, délais ou états nécessaires à votre modèle voyage.

À demander : Quelles opérations et quels états sont exposés pour le moyen local retenu, et comment les rapprocher avec la prestation ?

Documentation principale · consultée le 07/10/2026

Faits, limites et références (1)

Limite : Changer de route ou de prestataire ne dispense pas de rechercher l’état d’une tentative incertaine avant de la relancer.

À demander : Quelle référence rapproche les tentatives et comment un fallback évite-t-il un double encaissement lorsque le premier état est inconnu ?

Documentation principale · consultée le 06/10/2026

Faits, limites et références (1)

Limite : La conservation d’un token ne prouve pas la portabilité de tous les moyens ni l’acceptation par chaque prestataire ; les droits et formats doivent être confirmés.

À demander : Quels moyens, tokens et prestataires sont compatibles, et quelle procédure de migration permet de vérifier leur réutilisation ?

Documentation principale · consultée le 06/10/2026

Faits, limites et références (1)

Limite : Acceptation et paiement vers un bénéficiaire ne sont pas la même opération. Les corridors, contrôles, délais et possibilités de retour doivent être établis pour le flux contractualisé.

À demander : Quels corridors sont ouverts à notre entité, et quels états et références permettent de suivre un paiement reçu, en attente, rejeté ou retourné ?

Documentation principale · consultée le 08/10/2026

Faits, limites et références (1)

Limite : Compte, conversion et transfert sont des objets distincts ; une couverture affichée ne démontre pas chaque combinaison de pays, devise et bénéficiaire.

À demander : Comment bénéficiaire, conversion, règlement et référence de dossier sont-ils rapprochés sur le corridor retenu ?

Documentation principale · consultée le 07/10/2026

Faits, limites et références (1)

Limite : Ces fonctions ne décrivent pas automatiquement un PSP de réservation grand public ; éligibilité, bénéficiaires, devises et opérations doivent être établis.

À demander : Quels flux professionnels sont autorisés et quelles références rapprochent facture, paiement reçu et règlement fournisseur ?

Documentation principale · consultée le 08/10/2026

Faits, limites et références (1)

Limite : Le groupe ne correspond pas à une seule API ni à une même offre disponible dans tous les pays. Le nom exact du produit et l’entité contractante sont indispensables pour une comparaison exploitable.

À demander : Quelle solution précise est proposée à notre activité, avec quelles opérations, conditions locales, données de règlement et assistance ?

Documentation principale · consultée le 08/10/2026

Faits, limites et références (1)

Limite : Le lien créé n’est pas un paiement reçu ; expéditeur, référence, états et montant doivent être reliés au dossier et au contrat de paiement.

À demander : Comment une demande envoyée est-elle distinguée d’un règlement confirmé, et quel circuit contrôle relance et remboursement ?

Documentation principale · consultée le 08/10/2026

Faits, limites et références (1)

Limite : La présence de Klarna ne garantit pas un paiement fractionné pour toute offre touristique. Pays, marchand, transaction et décision d’éligibilité peuvent modifier les possibilités proposées au client.

À demander : Quels produits de paiement sont autorisés pour notre activité et comment sont traités capture, annulation et remboursement partiel du voyage ?

Documentation principale · consultée le 08/10/2026

Faits, limites et références (2)

Limite : Règle de la documentation Alma ; le circuit applicable dépend du montage. Aucun remboursement ni modification d’échéancier exécuté.

À demander : Le même endpoint couvre-t-il un reversement par carte virtuelle ?

Documentation principale · consultée le 10/10/2026

Autres références pour ce périmètre

• Alma : éligibilité · consultation du 08/10/2026

  Le contrôle d’éligibilité permet d’obtenir l’échéancier proposé ou un motif de non-éligibilité avant de présenter le moyen.

Faits, limites et références (1)

Limite : Le moyen de paiement et le prestataire de traitement ont des rôles distincts ; compatibilité, contrat marchand et suivi financier doivent être vérifiés.

À demander : Quel prestataire traite le paiement et comment dossier, résultat et remboursement sont-ils rapprochés ?

Documentation principale · consultée le 08/10/2026

Faits, limites et références (2)

Limite : Méthodes du client web Google Pay ; elles ne constituent pas la preuve d’un paiement exécuté par le prestataire financier.

À demander : isReadyToPay prouve-t-il que le paiement a réussi ?

Documentation principale · consultée le 10/10/2026

Autres références pour ce périmètre

• Google Pay : parcours web · consultation du 08/10/2026

  La documentation décrit la sélection d’un moyen et le retour d’un jeton, transmis au backend puis au prestataire de paiement pour exécuter l’achat.

Faits, limites et références (1)

Limite : Un compte client Amazon et un contrat marchand Amazon Pay ne donnent pas les mêmes droits. Disponibilité géographique, intégration et opérations après paiement doivent être confirmées pour le projet.

À demander : Quel parcours et quelle version sont proposés, et comment rapprocher paiement, annulation et remboursement du dossier de réservation ?

Documentation principale · consultée le 08/10/2026

Faits, limites et références (1)

Limite : Une présentation de paiement bancaire ne garantit pas toute banque, toute devise ni le même délai de règlement. Les retours d’état et les opérations de remboursement doivent être qualifiés dans l’intégration.

À demander : Quelles banques et devises sont couvertes pour le compte, et quels états prouvent paiement accepté, règlement et remboursement ?

Documentation principale · consultée le 08/10/2026

Faits, limites et références (1)

Limite : Présentation commerciale ; schéma bancaire, calendrier, mandat, règlement et recours doivent être précisés pour le marché et le produit.

À demander : Comment le suivi distingue-t-il l’accord de prélèvement, la collecte prévue et le règlement effectivement retrouvé ?

Documentation principale · consultée le 18/10/2026

Contrôles proposés pour ce périmètre

Parcours

À réunir : Cas fictif : acompte de 150 € et solde de 450 € prévus à deux dates. Identifier le produit bancaire retenu et les références de chaque échéance, sans les assimiler à deux paiements instantanés.

Accord

À réunir : Mandat ou accord requis selon le parcours et état à vérifier. Retrouver la preuve applicable sans déduire son existence d’une simple fiche client remplie.

Échéance

À réunir : Acompte réglé, solde seulement programmé dans l’exercice. Conserver 150 € connus et 450 € à suivre ; la programmation ne vaut pas encaissement.

Incident

À réunir : Collecte du solde échouée après préparation du départ. Attribuer la reprise et le contrôle de prestation ; ne pas répéter toute la série sans lire les résultats.

Faits, limites et références (1)

Limite : L’accès technique ne dispense pas de qualifier les acteurs et documents du circuit financier ; les fonctions retenues doivent correspondre au modèle de vente.

À demander : Qui est marchand pour chaque prestation et comment pièces KYC, blocages et versements sont-ils suivis avant ouverture des ventes ?

Documentation principale · consultée le 06/10/2026

Faits, limites et références (1)

Limite : Le document annonce une disponibilité API des objets de treize mois depuis CreationDate ; cela ne définit pas la conservation comptable du projet.

À demander : Comment retrouver le sens, le résultat et l’historique nécessaire de chaque mouvement du dossier ?

Documentation principale · consultée le 18/10/2026

Contrôles proposés pour ce périmètre

Objet

À réunir : Id, Type, Nature et wallets. Distinguer mouvement initial et contexte de remboursement.

Résultat

À réunir : Status et ExecutionDate. Ne pas lire CREATED comme un mouvement exécuté.

Montant

À réunir : Devise, montant et frais. Rapprocher des unités compatibles sans confondre net et brut.

Historique

À réunir : Période et objets encore disponibles via API. Vérifier la profondeur avant de promettre une reprise d’anciens dossiers.

Faits, limites et références (1)

Limite : Les produits, moyens de paiement et options de traitement ne sont pas nécessairement tous inclus dans une offre. La réservation fournisseur et le paiement marchand restent des opérations distinctes.

À demander : Comment retrouver autorisation, capture, remboursement et référence de réservation, notamment après modification ou échec de confirmation ?

Documentation principale · consultée le 08/10/2026

Faits, limites et références (1)

Limite : La documentation d’une connexion ne signifie pas activation de tous les moyens de paiement. Contrats, pays, devises et opérations financières doivent être vérifiés pour les marchands et fournisseurs concernés.

À demander : Quel flux relie dossier, paiement, règlement et remboursement, avec quels identifiants et moyens effectivement activés ?

Documentation principale · consultée le 08/10/2026

Faits, limites et références (3)

Limite : La table technique ne confirme ni l’activation d’une devise sur le compte ni les conditions de règlement, les frais ou un taux de change.

À demander : Appliquer la table de l’API et conserver aussi le code monétaire.

Documentation principale · consultée le 31/10/2026

Autres références pour ce périmètre

• Adyen : API idempotency · consultation du 17/10/2026

  Adyen documente une clé d’idempotence pour les requêtes POST. Si une réponse porte transient-error: true, une nouvelle tentative peut réutiliser la même clé après attente. Un doublon déjà en cours peut renvoyer HTTP 409 ou 422, code 704 ; une réponse perdue ne justifie pas une nouvelle clé.

  Portée : Gestion des tentatives répétées et erreurs transitoires ; la clé ne coordonne pas les doublons entre points d’accès régionaux simultanés.

• Adyen : Currency codes · consultation du 05/10/2026

  Le montant exige une devise et une convention d’unité ; certaines précisions diffèrent d’ISO 4217.

Contrôles proposés pour ce périmètre

Exceptions

À réunir : CLP, CVE, IDR et ISK ont un nombre de décimales Adyen différent de la référence ISO 4217.. Appliquer la table de l’API et conserver aussi le code monétaire.

ISK

À réunir : Pour l’ISK, la référence ISO indique zéro décimale, tandis qu’Adyen en demande deux pour le montant transmis.. Un montant de 10 ISK s’écrit 1000 selon cette convention Adyen ; ce calcul n’est pas un taux de change.

Périmètre

À réunir : Les règles présentées concernent les API soumises à la convention en unités mineures, hors Terminal API.. Relire le contrat de l’opération avant de transposer un encodage utilisé ailleurs.

Données et contrôles d’intégration

Adyen attribue une référence à la demande de remboursement. Le webhook REFUND en décrit la validation ; des événements ultérieurs peuvent signaler échec ou retour.

Paiement initial

Conserver paymentPspReference.

Demande

Rapprocher la pspReference du remboursement du dossier.

Notification

Suivre REFUND puis les éventuels REFUND_FAILED ou REFUNDED_REVERSED.

Scénario proposé : Rejouer le traitement d’une validation suivie d’un échec, en corrigeant le statut visible et le rapprochement comptable.

Portée : La validation de la demande ne garantit pas un crédit définitif sur le compte du voyageur.

Contrôles éditoriaux proposés, à rejouer sur votre périmètre ; aucun appel à une API fournisseur ni test de réservation effectué.

Référence et notification de remboursement · consultation du 13/10/2026

Faits, limites et références (1)

Limite : Liste d’événements recommandés ; une approbation ne démontre pas à elle seule la capture ni la confirmation du voyage.

À demander : Quels événements et relectures permettent de conclure pour chaque étape de votre paiement ?

Documentation principale · consultée le 18/10/2026

Contrôles proposés pour ce périmètre

Identité

À réunir : Paiement, opération et dossier. Relier chaque notification au bon mouvement.

Capture

À réunir : Approbation puis capture ou refus. Éviter de clore le suivi financier sur l’approbation seule.

Remboursement

À réunir : Opération et résultat ou refus. Retrouver le mouvement qui réalise la décision commerciale.

Attente

À réunir : Moyen concerné et état courant. Attribuer la suite quand le résultat financier est différé.

Faits, limites et références (1)

Documenté : WEX présente des cartes virtuelles pour régler les fournisseurs du voyage et faciliter le rapprochement.

Limite : Cette fonction de règlement fournisseur ne remplace pas automatiquement l’encaissement du voyageur.

À demander : Qui accepte la carte, à quelle date, pour quel montant et avec quel traitement d’un remboursement ?

Documentation principale · consultée le 01/10/2026

Faits, limites et références (1)

Limite : L’accès du voyageur à une carte ne garantit pas son acceptation ni la transmission des consignes à l’hôtel.

À demander : Que voit la réception et qui intervient si le paiement ne peut pas être réalisé à l’arrivée ?

Documentation principale · consultée le 06/10/2026

Faits, limites et références (1)

Limite : Une limite de carte et le montant final dû à l’établissement doivent être rapprochés séparément.

À demander : La fenêtre et la devise autorisées correspondent-elles au débit attendu et aux frais convenus ?

Documentation principale · consultée le 06/10/2026

Faits, limites et références (9)

Limite : Documentation de capture différée Stripe. L’éligibilité multicapture et les règles propres au moyen de paiement doivent être vérifiées séparément.

À demander : Vérifier l’état et le montant demandé avant l’action.

Documentation principale · consultée le 31/10/2026

Autres références pour ce périmètre

• Stripe — Refund and cancel payments · consultation du 22/10/2026

  Un remboursement retourne au moyen de paiement d’origine, pas à une autre carte ou à un autre compte choisi dans la demande.

  Portée : Règles Stripe ; les montages Connect et les délais du moyen de paiement demandent une lecture propre à leur périmètre.

• Stripe — requêtes idempotentes · consultation du 27/10/2026

  Le chemin de l’API et sa version sont deux informations distinctes. Ne transposez pas les règles /v2 à un paiement /v1.

• Stripe — différences entre /v1 et /v2 · consultation du 27/10/2026

  Le chemin de l’API et sa version sont deux informations distinctes. Ne transposez pas les règles /v2 à un paiement /v1.

• Stripe Connect : dossier transmis, paiement et versement restent distincts · consultation du 22/10/2026

  charges_enabled et payouts_enabled indiquent séparément la possibilité de créer des paiements et de recevoir des versements. currently_due rassemble les exigences à résoudre avant current_deadline. eventually_due contient celles qui peuvent devenir nécessaires selon les seuils atteints. past_due contient les exigences dont le dépassement d’échéance a désactivé des capacités ; pending_verification signale une vérification en cours. Stripe demande de surveiller account.updated ; disabled_reason et errors aident à comprendre le blocage.

  Portée : Référence technique Connect consultée le 22 octobre 2026. Les exigences dépendent notamment du pays, du type d’entreprise et des capacités demandées. Cette vérification financière ne valide ni le contrat touristique ni la qualité des offres.

• Stripe Payment Links : distinguer compteur de sessions et réservation · consultation du 22/10/2026

  restrictions.completed_sessions.count compte les sessions Checkout terminées retenues pour la restriction ; limit en fixe le maximum. Avec active: false, l’URL affiche au visiteur un message indiquant que le lien a été désactivé. livemode distingue un objet de production d’un objet de test. submit_type: book adapte le bouton à une réservation et utilise le domaine book.stripe.com.

  Portée : Référence API Stripe consultée le 22 octobre 2026. Une session terminée est une notion du parcours Checkout : rapprochez le résultat financier et la confirmation de prestation avant d’envoyer le message final.

• Stripe — réponse aux contestations dans le Dashboard · consultation du 22/10/2026

  Stripe distingue les inquiries d’une contestation formelle ; une escalade exige une nouvelle réponse. Le parcours Dashboard n’offre qu’une soumission de la réponse, ensuite non modifiable ni complétable par de nouveaux fichiers.

  Portée : Gestion d’une contestation dans le Dashboard, consultée le 22 octobre 2026. Ces indications ne sont ni une garantie de résultat bancaire ni la preuve d’un droit d’API accordé à un compte.

• Stripe Invoicing — Accept partial payments for invoices · consultation du 22/10/2026

  Stripe demande un PaymentIntent de même devise et de même client que la facture, pour un montant au plus égal au restant dû. Sur la page de facture hébergée, les paiements partiels doivent être activés dans les paramètres Invoice.

  Portée : Périmètre Stripe Invoicing consulté le 22 octobre 2026. Une facture, un acompte contractuel de voyage et la confirmation de prestation ont des états et des règles à rapprocher séparément.

• Stripe : distinguer cadence, concurrence et verrouillage · consultation du 27/10/2026

  Stripe-Rate-Limited-Reason distingue notamment global-rate et endpoint-rate. global-concurrency et endpoint-concurrency concernent les requêtes simultanément en cours. Un 429 sans cet en-tête n’est pas produit par le limiteur de cadence ; la documentation cite notamment les lock timeouts.

  Portée : Périmètre Stripe. La documentation recommande un recul exponentiel avec dispersion aléatoire pour les reprises de limitation. L’état du paiement doit rester rapproché de celui de la réservation.

Contrôles proposés pour ce périmètre

État préalable

À réunir : Après autorisation, le PaymentIntent passe à requires_capture ; la capture prend par défaut tout le montant autorisé.. Vérifier l’état et le montant demandé avant l’action.

Capture partielle

À réunir : amount_to_capture permet une capture inférieure ; le reste est automatiquement libéré dans le parcours standard.. Ne pas planifier une seconde capture sur ce reste sans vérifier la capacité réellement disponible.

Exception

À réunir : La plupart des paiements n’acceptent qu’une capture ; certains paiements par carte sont éligibles à multicapture.. Traiter la capture multiple comme une capacité à vérifier pour le paiement concerné.

Données et contrôles d’intégration

Stripe distingue annulation d’un paiement non capturé et remboursement d’un paiement réussi. Plusieurs remboursements partiels restent rattachés au paiement initial.

Paiement original

Conserver l’identifiant charge ou PaymentIntent.

Montant

Rapprocher amount, devise et unités monétaires.

État du remboursement

Suivre les événements et les échecs éventuels.

Scénario proposé : Rapprocher deux remboursements partiels d’un séjour avec leur paiement initial sans annoncer un remboursement abouti sur la seule demande.

Portée : Le montant remboursé ne peut dépasser le paiement initial ; délais et comportement varient selon le moyen de paiement.

Contrôles éditoriaux proposés, à rejouer sur votre périmètre ; aucun appel à une API fournisseur ni test de réservation effectué.

Remboursements et états financiers · consultation du 13/10/2026

Faits, limites et références (1)

Documenté : La documentation prévoit des événements dupliqués partageant eventCode et pspReference et recommande de prendre en compte leur chronologie.

Limite : L’événement de paiement et la confirmation de réservation doivent être rapprochés séparément.

À demander : Comment une notification répétée ou retardée est-elle traitée sans double action ?

Documentation principale · consultée le 02/10/2026

Faits, limites et références (1)

Limite : Le programme ne signifie pas acceptation automatique par tout fournisseur ni accès direct pour toute agence. Émetteur, conditions, devise et moment d’utilisation doivent être précisés.

À demander : Comment relier carte virtuelle, fournisseur, montant autorisé et réservation, puis traiter changement de séjour ou remboursement ?

Documentation principale · consultée le 08/10/2026

Faits, limites et références (1)

Limite : La présentation d’une gamme ne garantit pas tous les moyens, pays ou opérations au même contrat. Les performances marketing ne constituent pas une promesse de taux d’acceptation pour le voyage.

À demander : Quels moyens et flux sont activés, avec quelles références pour autorisation, capture, règlement, annulation et contestation ?

Documentation principale · consultée le 08/10/2026