Méthodes d'intégration du checkout. 6 chapitres et un QCM final.

Chapitre 1. Le checkout, nerf de la conversion.

La page de paiement est l'endroit le plus rentable d'un site marchand, et le plus fragile. La conversion finale s'y joue, la réglementation PCI DSS s'y applique, les attaques s'y concentrent (skimming, phishing). Choisir sa méthode d'intégration, c'est arbitrer entre trois forces, l'expérience utilisateur que l'on veut offrir, le périmètre de conformité que l'on peut assumer et l'effort d'ingénierie disponible.

Toutes les méthodes d'intégration répondent à la même question, qui voit passer les données de carte. Plus le marchand s'en approche, plus il gagne en contrôle sur l'expérience. Et plus son périmètre PCI DSS s'alourdit. Le questionnaire d'auto-évaluation (SAQ) qui en découle va d'une trentaine de questions (SAQ A) à plusieurs centaines (SAQ D). Le choix technique est d'abord un choix de conformité.

Chapitre 2. Redirection hébergée : la voie express.

La redirection est la méthode historique, et la plus simple. Au moment de payer, le client est redirigé vers une page hébergée par le PSP (ou vers le wallet de son choix, PayPal ou Wero). Il y saisit sa carte, subit l'éventuel 3-D Secure, puis revient sur le site marchand. Les données de carte ne s'approchent jamais des serveurs ni du navigateur « côté marchand », si bien que le périmètre PCI est réduit au strict minimum.

• Avantages : intégration en quelques jours, périmètre SAQ A, page maintenue par le PSP (3DS, nouvelles méthodes, traductions, accessibilité), idéale sans équipe front dédiée
• Limites : rupture de parcours (changement de domaine), personnalisation restreinte (logo, couleurs, rarement plus), dépendance à l'UX du PSP, URL de retour à fiabiliser
• Piège classique : considérer le retour navigateur comme preuve de paiement, alors que la confirmation doit venir du webhook

Côté conversion, la redirection a mauvaise réputation : « on perd le client en route ». La réalité est plus nuancée. Pour un petit marchand, une page PSP soignée, rapide et rassurante convertit souvent mieux qu'un formulaire maison approximatif. Le coût réel se paie sur mobile (redirections lentes, retours ratés depuis les apps bancaires) et pour les marques fortes, dont l'identité disparaît au moment décisif.

Chapitre 3. Iframe et hosted fields : le sur-mesure encadré.

Avec les hosted fields (champs hébergés), le client ne quitte plus le site. Le formulaire de paiement appartient au marchand, mais chaque champ sensible (numéro de carte, expiration, cryptogramme) est en réalité une iframe servie depuis le domaine du PSP. Les frappes clavier atterrissent directement chez le PSP, qui renvoie un token au marchand. Visuellement intégré, techniquement cloisonné, ce compromis domine le e-commerce moderne (Stripe Elements, Braintree Hosted Fields, Adyen Components…).

<form id="paiement">
  <label>Numero de carte</label>
  <div id="champ-pan"></div>   <!-- iframe injectee par le PSP -->
  <label>Expiration</label>
  <div id="champ-exp"></div>
  <label>Cryptogramme</label>
  <div id="champ-cvc"></div>
  <button id="payer" type="button">Payer 49,90 EUR</button>
</form>

<script src="https://js.psp.example/v3/fields.js"></script>
<script>
  const fields = Psp.fields("pk_live_xxx", {
    style: { base: { fontFamily: "Inter", fontSize: "16px", color: "#1a1a2e" } }
  });
  fields.mount("#champ-pan", "cardNumber");
  fields.mount("#champ-exp", "cardExpiry");
  fields.mount("#champ-cvc", "cardCvc");

  document.querySelector("#payer").addEventListener("click", async () => {
    // Le PAN part directement des iframes vers le PSP :
    // seul un token revient au marchand.
    const result = await fields.tokenize();
    await fetch("/api/payer", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ token: result.token })
    });
  });
</script>

Côté conversion, les hosted fields offrent le meilleur des deux mondes : un parcours sans rupture, une identité visuelle intacte, des messages d'erreur dans le ton de la marque. Les points de vigilance sont techniques. Temps de chargement des iframes (à précharger), gestion fine des erreurs de tokenisation, compatibilité avec les gestionnaires de mots de passe et l'autofill mobile. Mal traités, ces détails rendent le formulaire moins performant qu'une bonne page hébergée.

• Exemples PSP : Stripe Elements, Braintree Hosted Fields, Adyen Web Components (mode champs), Checkout.com Frames, Mollie Components
• Effort d'intégration : quelques semaines, avec un vrai travail front (états, erreurs, accessibilité)
• Bon candidat : marchand avec une marque forte, une équipe front, et un besoin de contrôle du parcours sans assumer le SAQ D

Chapitre 4. Drop-in : le composant tout-en-un.

Le drop-in pousse la logique des hosted fields un cran plus loin. Le PSP ne fournit plus des champs isolés mais un composant de checkout complet (carte, wallets, virement, BNPL, méthodes locales) qui s'affiche dans la page du marchand et s'auto-configure. Il décide lui-même quelles méthodes montrer selon le pays, l'appareil, la devise et le montant. Apple Pay sur iPhone, Wero pour un client français, Pix au Brésil, sans une ligne de code supplémentaire.

• Méthodes dynamiques : l'ajout d'un moyen de paiement se fait en configuration côté PSP, pas en développement côté marchand
• Mises à jour automatiques : nouvelles versions de 3DS, nouveaux wallets, correctifs de sécurité livrés par le script du PSP
• Optimisations embarquées : ordre des méthodes, mémorisation de carte, localisation. Le PSP fait de l'A/B testing à votre place
• Time-to-market : un checkout multi-méthodes présentable en quelques jours

Sur le plan PCI DSS, le drop-in hérite du modèle iframe. Les données sensibles sont saisies dans des cadres servis par le PSP, et le marchand reste en général éligible au SAQ A, avec les mêmes obligations de surveillance des scripts de sa page (PCI DSS v4.0). Le rapport effort/résultat reste aujourd'hui le meilleur pour la grande majorité des marchands. Une fois le drop-in adopté, la question qui reste ouverte est celle du moment où les besoins de personnalisation justifieront d'en sortir.

Chapitre 5. API directe : la puissance au prix du PCI.

Reste une dernière option, où le marchand collecte lui-même les données de carte (formulaire natif, application mobile, centre d'appel) et les transmet à l'API du PSP depuis ses propres serveurs. Contrôle absolu de l'expérience, liberté totale d'architecture : vault de cartes maison, routage multi-PSP, retry intelligent. La contrepartie est maximale. Les systèmes du marchand entrent de plain-pied dans le périmètre PCI DSS, avec le questionnaire SAQ D et, au-delà de 6 millions de transactions annuelles, un audit sur site par un QSA.

L'API directe se justifie chez les acteurs qui font du paiement un avantage compétitif : grandes plateformes opérant leur propre vault et leur orchestration multi-PSP (routage au meilleur taux d'autorisation, bascule en cas de panne), vente à distance par téléphone (MOTO), ou secteurs aux parcours très spécifiques. Pour les autres, une voie médiane existe, celle des proxys de tokenisation (VGS, Basis Theory…) qui interceptent les données de carte à la volée. Le multi-PSP devient possible sans faire entrer le PAN dans ses systèmes, et donc sans SAQ D.

Chapitre 6. Choisir : le grand comparatif.

Il n'existe pas de meilleure méthode dans l'absolu, mais une méthode adaptée à un profil de marchand, à un moment donné. Le tableau qui suit condense les cinq chapitres précédents ; relisez-le à chaque étape de croissance, car la réponse change quand l'équipe, le volume ou l'ambition internationale changent.

• Erreur n° 1 : choisir l'API directe « pour garder le contrôle » sans avoir budgété la conformité SAQ D. Le contrôle coûte des centaines de jours-homme
• Erreur n° 2 : intégrer des iframes puis laisser la page qui les entoure sans surveillance de scripts. C'est la cible favorite du skimming Magecart, et une exigence v4.0
• Erreur n° 3 : déployer une redirection avec une page PSP mal configurée (langue, logo, méthodes absentes) et conclure que « la redirection convertit mal »
• Erreur n° 4 : ne pas instrumenter le funnel. Sans mesure du taux de complétion du checkout par méthode et par appareil, tout débat sur la conversion est de l'opinion