Démo en ligne

API de paiement pour le voyage

API de passerelle de paiement pour réservations de voyage : du paiement au remboursement

Une API de passerelle de paiement permet à votre site de réservation d'encaisser le voyageur sans jamais toucher à la carte. Cette page détaille les appels d'un paiement par carte, les statuts qu'il traverse, ce qui rend les paiements de voyage plus difficiles que ceux du commerce et comment PHPTRAVELS relie votre parcours de réservation à la passerelle de votre choix.

  • Session, 3-D Secure, capture
  • Tous les statuts de paiement
  • Cartes, wallets, virement, crédit
  • Aucune donnée de carte sur votre serveur

Comment fonctionnent les appels

Un paiement par carte, appel par appel

Une API de passerelle de paiement est un ensemble de services web qu'un prestataire de paiement ouvre aux marchands. Votre serveur lui demande de créer un paiement pour un montant et une devise, le voyageur saisit sa carte dans le formulaire de la passerelle, et celle-ci dialogue avec le réseau de cartes et la banque émettrice. Votre serveur ne voit jamais le numéro de carte : il reçoit un ID de paiement et un statut.

Quatre acteurs interviennent. Le schéma les montre en colonnes et chaque message en flèche numérotée. Les noms varient d'une passerelle à l'autre (payment intent, session, commande, débit), mais la séquence est la même.

Un voyageur qui paie un voyage en ligne pendant qu'un site de réservation, une passerelle de paiement et une banque échangent des messages de paiement

La flèche en pointillés est un webhook : la passerelle appelle votre serveur d'elle-même, si bien que le paiement met à jour la réservation même si le voyageur ferme son navigateur. La page Intégration de passerelles de paiement explique comment chaque étape est rattachée à une réservation dans PHPTRAVELS.

  • Voyageur
  • Votre site
  • Passerelle
  • Réseau de cartes / banque

  1. 01PaiementVoyageur Votre site

    Le voyageur vérifie son voyage et clique sur Payer. La réservation est mise en attente chez le fournisseur, pas encore confirmée.

  2. 02Créer le payment intent ou la sessionVotre site Passerelle

    Votre serveur envoie montant, devise, référence de réservation et clé d'idempotence avec sa clé API secrète. La passerelle renvoie un ID de paiement.

  3. 03Champs hébergés ou redirectionPasserelle Voyageur

    Le formulaire de carte est fourni par la passerelle, dans votre page ou sur la sienne, de sorte que les données de carte lui arrivent directement.

  4. 043-D SecureRéseau de cartes / banque Voyageur

    Si la banque émettrice le demande, le voyageur confirme le paiement dans son application bancaire ou avec un code à usage unique.

  5. 05AutorisationPasserelle Réseau de cartes / banque

    La passerelle demande à l'émetteur, via le réseau de cartes, d'approuver le montant.

  6. 06Approuvé, fonds bloquésRéseau de cartes / banque Passerelle

    L'émetteur réserve l'argent sur la carte. Rien n'a encore été débité.

  7. 07Résultat vers votre sitePasserelle Votre site

    Le voyageur revient sur votre site avec l'ID de paiement. Votre serveur lit le statut via l'API et confirme la réservation auprès du fournisseur.

  8. 08CaptureVotre site Passerelle

    Une fois le fournisseur confirmé, votre serveur capture le montant total ou un montant inférieur. De nombreuses passerelles peuvent aussi capturer immédiatement.

  9. 09WebhookPasserelle Votre siteEnvoyé par la passerelle d'elle-même

    La passerelle envoie à votre endpoint un événement signé (paiement capturé, remboursé, contesté). Votre serveur vérifie la signature et met à jour la réservation.

Statuts de paiement

La vie d'un paiement comme machine à états

Chaque API de passerelle indique un statut pour chaque paiement. Les termes varient, mais ils correspondent aux mêmes quelques états, et la logique de votre réservation doit réagir à chacun.

  1. created

    Créé

    Le paiement existe avec un montant et une devise, en attente du voyageur.

    failedFinal

    Échoué

    Refusé, 3-D Secure non terminé ou abandonné. Rien n'est débité.

  2. authorized

    Autorisé

    L'émetteur a approuvé le montant et le bloque sur la carte.

    voidedFinal

    Annulé

    Le blocage est levé avant la capture : le voyageur n'est jamais débité.

  3. captured

    Capturé

    L'argent est encaissé et sera versé sur votre compte marchand.

    partially_refundedFinal

    Remboursé partiellement

    Une partie du montant capturé est restituée, par exemple après des frais d'annulation.

    refundedFinal

    Remboursé

    La totalité du montant capturé est restituée sur la carte.

Une autorisation ne dure pas indéfiniment : si elle n'est pas capturée à temps, le blocage expire et la banque libère l'argent. Un paiement partiellement remboursé peut encore l'être, jusqu'au montant capturé.

Pourquoi le voyage est plus complexe

Pourquoi les paiements de voyage sont différents

Une boutique vend ce qu'elle a en stock. Un vendeur de voyages encaisse une réservation que le fournisseur doit encore confirmer, souvent des mois avant le départ. L'API de paiement doit s'y adapter.

  • 01

    Autoriser maintenant, capturer plus tard

    Les hôtels sur demande, tarifs groupes et circuits sont confirmés des heures ou des jours après la commande. Autoriser d'abord et capturer à la confirmation évite de débiter une réservation qui n'aboutit pas.

  • 02

    Le fournisseur peut encore refuser

    Un tarif peut être épuisé entre le paiement et l'émission. Avec une autorisation, l'argent est libéré par une annulation ; après capture, il devient un remboursement.

  • 03

    Remboursements partiels après frais d'annulation

    Annuler un séjour ou un billet entraîne généralement des frais. L'appel de remboursement envoie un montant inférieur sur le paiement d'origine, autant de fois que les règles l'exigent.

  • 04

    Multidevise

    Les voyageurs paient dans leur devise alors que les fournisseurs facturent dans la leur. La passerelle doit gérer la devise de présentation, et vos enregistrements doivent conserver les deux montants.

  • 05

    Contrôles antifraude sur les montants élevés

    Des billets pour demain, pour un tiers, payés avec une nouvelle carte : un schéma de fraude classique. 3-D Secure, le score de risque de la passerelle et une file de vérification manuelle protègent les commandes de forte valeur.

  • 06

    Rétrofacturations des mois plus tard

    Les litiges arrivent souvent après le voyage. Conservez ensemble le résultat d'authentification, les documents de réservation et les événements de la passerelle pour répondre à chacun avec des preuves.

Moyens de paiement

Quels moyens de paiement couvre une API de passerelle de paiement

La carte n'est qu'une option. Voyageurs et agents paient de différentes façons, et chacune se rembourse différemment.

MoyenDe quoi s'agit-ilQuand l'argent arriveRemboursements
CartesCartes de débit et de crédit via la passerelle, avec 3-D Secure lorsque l'émetteur l'exige.Autorisé au paiement ; capturé aussitôt ou à la confirmation du fournisseur.Remboursement total ou partiel sur la même carte via l'API.
Portefeuilles numériquesComptes wallet pris en charge par la passerelle, comme PayPal ou un portefeuille mobile contenant une carte tokenisée.Au paiement, une fois que le voyageur valide dans son wallet.Retour vers le wallet ou la carte associée, via la passerelle.
Virement bancaireLe voyageur ou l'agent envoie l'argent sur votre compte bancaire et le paiement est enregistré sur la réservation.Quelques jours plus tard ; la réservation attend que votre équipe confirme la réception.Remboursé par virement, hors passerelle.
Payer plus tardLa réservation est faite maintenant et payée plus tard ; votre équipe enregistre le paiement à son arrivée.Après la réservation, quand le voyageur paie.Seul le montant réellement payé est restitué.
Wallet ou crédit d'agent B2BLes sous-agents paient avec un solde approvisionné à l'avance ou une ligne de crédit que vous accordez.Débité à la réservation ; dépôts et crédit réglés selon vos conditions.Recrédité sur le solde de l'agent.

Virement, payer plus tard et solde wallet sont des modes de règlement de la plateforme elle-même, pas des passerelles. Les soldes et lignes de crédit des agents sont expliqués sur la page Portefeuille agent B2B ; les paiements bancaires sur la page Paiement par virement bancaire.

Prêt dans PHPTRAVELS

API de passerelle de paiement déjà connectées

Ces passerelles sont déjà connectées à PHPTRAVELS. Vous ouvrez un compte marchand chez le prestataire, saisissez vos clés API dans l'admin, testez dans son sandbox puis passez en production. La liste est celle, en direct, de notre annuaire d'intégrations.

Les frais et l'agrément marchand se négocient avec le prestataire de paiement, pas avec PHPTRAVELS. Une passerelle absente de la liste peut être ajoutée comme Intégration d'API sur mesure, et la page Intégration de passerelles de paiement explique comment chacune est configurée.

Sécurité

Garder les données de carte hors de votre système

Le numéro de carte le plus sûr est celui que votre serveur ne reçoit jamais. Une API de passerelle de paiement est conçue pour que ce ne soit pas nécessaire.

  • Ne jamais stocker les numéros de carte

    Les données de carte vont à la passerelle, qui renvoie un jeton ou un ID de paiement. Votre base de données conserve cette référence, jamais le numéro de carte ni le cryptogramme.

  • Champs hébergés et redirections réduisent le périmètre PCI DSS

    Le PCI DSS s'applique à quiconque manipule des données de carte. Quand le formulaire est la page de la passerelle ou des champs intégrés, une part bien moindre de votre système entre dans le périmètre. Votre acquéreur indique quel questionnaire d'auto-évaluation vous concerne.

  • Webhooks vérifiés par signature

    Chaque webhook porte une signature calculée avec un secret partagé. Votre serveur la recalcule et rejette tout événement non conforme, afin que personne ne puisse simuler une réservation payée.

  • Les clés secrètes restent sur le serveur

    Le navigateur ne reçoit qu'une clé publique. La clé secrète qui crée paiements et remboursements reste dans la configuration de votre serveur, et chaque requête porte une clé d'idempotence pour qu'une nouvelle tentative ne débite jamais deux fois.

webhook.php
 1$payload   = file_get_contents("php://input"); 2$signature = $_SERVER["HTTP_X_SIGNATURE"] ?? ""; 3$expected  = hash_hmac("sha256", $payload, $webhookSecret); 4 5if (!hash_equals($expected, $signature)) { 6    http_response_code(400); exit;      // reject 7} 8$event = json_decode($payload, true); 9if (alreadyHandled($event["id"])) exit; // repeat delivery10updateBooking($event["data"]["metadata"]["booking_ref"], $event["type"]);

Exemple générique. Les noms d'en-têtes et la méthode de signature dépendent de la passerelle choisie.

PHPTRAVELS est un logiciel auto-hébergé : la conformité PCI DSS s'évalue pour votre entreprise et votre serveur, pas pour le seul logiciel.

Voir une réservation payée, capturée et remboursée

Réservez un voyage dans la démo en ligne et suivez le paiement dans l'admin. Avec l'offre Enterprise, PHPTRAVELS fournit aussi sa propre REST API et ses webhooks pour vos applications et partenaires.

Vous vendez aussi des vols ? La page API de vols explique le côté fournisseur, et API de voyage liste toutes les API que PHPTRAVELS connecte.

Essayer la démo en ligneComparer les offresLire la documentation développeur

FAQ

API de passerelle de paiement : les questions des vendeurs de voyages

Parler à un conseiller

C'est un ensemble de services web fournis par un prestataire de paiement pour qu'un site puisse créer des paiements, envoyer la carte à la banque pour approbation, capturer l'argent, émettre des remboursements et recevoir des mises à jour de statut par webhook, sans stocker de données de carte.

La passerelle est la partie avec laquelle votre site dialogue : elle collecte la carte en sécurité et transmet la demande. Le processeur fait transiter la transaction par les réseaux de cartes jusqu'à la banque émettrice. De nombreux prestataires proposent les deux dans un seul service.

Celle qui agrée votre activité, couvre les pays, devises et moyens de paiement de vos clients et propose autorisation et capture séparées ainsi que des remboursements partiels. Beaucoup d'agences combinent une passerelle carte mondiale et une passerelle régionale.

L'autorisation réserve le montant sur la carte du voyageur ; la capture l'encaisse. Les séparer permet de ne débiter qu'une fois la réservation confirmée par le fournisseur, et d'annuler le blocage dans le cas contraire.

Dans de nombreuses régions, dont l'Espace économique européen et le Royaume-Uni, l'authentification forte du client est exigée pour la plupart des paiements par carte en ligne, et 3-D Secure est le moyen pour les cartes d'y répondre. L'API de la passerelle gère le défi ; votre parcours de réservation attend le résultat.

Pas à elle seule. Utiliser les champs hébergés ou la page de paiement de la passerelle garde les données de carte hors de votre serveur et réduit votre périmètre PCI DSS, mais vous devez tout de même réaliser l'évaluation demandée par votre acquéreur.

Oui, si la passerelle gère les remboursements partiels, ce que font la plupart des passerelles carte. Vous envoyez un remboursement d'un montant inférieur sur le paiement d'origine, par exemple le prix moins des frais d'annulation.

Non. Vous ouvrez un compte marchand chez la passerelle de votre choix et en convenez les frais avec elle. PHPTRAVELS relie votre plateforme de réservation à ce compte grâce aux clés API que vous saisissez dans l'admin.

Oui. Toute passerelle dotée d'une API documentée peut être ajoutée comme intégration personnalisée et, le code source étant fourni, vos développeurs peuvent aussi étendre le parcours de paiement.

Continuez à explorer

Plus sur la plateforme