595 solutions pour construire votre écosystème B2B tourisme.

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 (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