🧱 Les méthodes d'intégration d'un prestataire de paiement

Le périmètre de conformité PCI DSS

Le périmètre de conformité PCI DSS rassemble les systèmes qui stockent, traitent ou transmettent des données de carte. La norme est publiée par le PCI Security Standards Council, l'organisme constitué par les réseaux de cartes internationaux. Le périmètre suit la donnée, et non l'organigramme. Un serveur que le numéro de carte traverse une seule fois y entre pour de bon.

Le SAQ (Self-Assessment Questionnaire) est le formulaire par lequel un marchand atteste lui-même de sa conformité. Sa variante dépend du chemin que suivent les données de carte dans son installation. Le SAQ A s'applique quand la collecte est entièrement servie par le prestataire, et il compte une trentaine de questions dans la version 4 du standard, contre 22 dans la version 3.2.1 qu'elle a remplacée. Le SAQ D s'applique dès que le numéro traverse les systèmes du marchand, et il en compte plusieurs centaines.

Entre les deux existe le SAQ A-EP, qui vise le marchand dont la page contrôle le formulaire de paiement tout en déléguant la collecte elle-même. Le numéro ne traverse pas ses serveurs, mais sa page décide de l'endroit où il part. Le questionnaire y est nettement plus étendu que le SAQ A, sans atteindre le SAQ D. Aucun des cinq montages décrits ici ne s'y trouve par construction ; un marchand y bascule par une modification de sa propre page, souvent sans l'avoir voulu.

Le périmètre déborde la page de paiement. Il couvre aussi les canaux où un numéro se dicte plutôt qu'il ne se saisit, le téléphone en étant l'exemple courant. Le lien de paiement répond à ce cas, puisqu'il encaisse sans site, sur devis, par téléphone ou entre entreprises, et que la saisie se déplace alors sur une page entièrement hébergée par le prestataire, celle qui relève du SAQ A.

Les cinq méthodes, comparées

Les cinq méthodes d'intégration décrites ci-dessous couvrent les façons d'encaisser une carte en ligne. Elles se distinguent par trois traits observables. Le premier porte sur le service des champs sensibles, le deuxième sur la liberté de mise en page, le troisième sur le lieu où le parcours se poursuit. Le schéma situe les quatre montages qui s'insèrent dans un site de vente, le lien de paiement se déroulant hors de tout parcours en ligne.

Quatre méthodes isolent les champs sensibles dans un cadre ou une page servis par le prestataire. L'interface serveur à serveur est la seule à ne pas le faire, et la seule à relever du SAQ D. Trois méthodes gardent le porteur sur le site du marchand, soit les champs hébergés, le composant prêt à poser et l'interface serveur à serveur. La redirection le conduit ailleurs avant de le ramener, quand le lien de paiement se passe entièrement de site.

Maîtrise du parcours et charge de conformité

L'arbitrage entre les cinq méthodes met en balance deux grandeurs. La première est la maîtrise du parcours, soit la latitude laissée au marchand sur la mise en page, sur la formulation des messages et sur l'enchaînement des écrans. La seconde est la charge de conformité, que mesurent le questionnaire à remplir et les contrôles qui l'accompagnent. Les deux varient en sens inverse. Le lien de paiement offre la maîtrise la plus faible pour la charge la plus légère, et l'interface serveur à serveur porte les deux à leur maximum.

La progression connaît une exception, et elle explique la place tenue par les champs hébergés. Ce montage laisse dessiner la page au pixel près tout en restant au SAQ A, parce que les champs sensibles demeurent servis par le prestataire. Le marchand compose donc sa page autour de cadres dont il ne lit pas le contenu. Il paie cette position par une intégration plus longue que celle d'un composant prêt à poser, et par une validation limitée aux événements que le prestataire expose.

La rupture de parcours désigne le moment où le payeur quitte le site marchand pour un autre domaine. La redirection en produit une, et le porteur la constate dans la barre d'adresse. Les champs hébergés et le composant la suppriment, le formulaire étant posé dans la page du marchand. Le dossier « La psychologie du passage en caisse » expose les principes de conversion que cette continuité met en jeu, chacun avec l'étude dont il est tiré.

La redirection hébergée

La redirection hébergée conduit le porteur hors du site du marchand, vers une page de paiement servie par le prestataire, puis le ramène ensuite. Le montage est le plus ancien des cinq, et il porte des offres comme PayZen, Worldline Sips ou Stripe Checkout. L'intégration demande quelques heures. Le marchand transmet le montant et la référence de la commande. Le prestataire sert la page, encaisse, puis renvoie le porteur avec le résultat de l'opération.

Ce que la redirection permet

• Aucune donnée de carte ne touche le système du marchand, ce qui réduit la conformité au minimum
• Toutes les méthodes de paiement sont gérées et mises à jour par le prestataire
• L'authentification, les portefeuilles et les nouvelles tentatives sont portés par l'hébergeur
• Le logo, les couleurs et les champs affichés restent personnalisables

Ce qu'elle interdit

• Maîtriser la mise en page au pixel près : le dessin reste celui du prestataire
• Éviter la rupture de parcours qu'introduit la redirection, et la perte de conversion qui l'accompagne
• Accéder aux données de carte, même transitoires
• Comparer finement deux versions du formulaire de paiement

Prestataires proposant couramment ce montageStripePAPayplugLYLyraWorldlineMOMollie

Les champs hébergés

Les champs hébergés remplacent chaque champ sensible par un cadre servi par le prestataire et posé dans la page du marchand. Le numéro, le cryptogramme et la date d'expiration vivent ainsi dans des cadres distincts, dont le marchand fixe les styles sans en lire le contenu. Le porteur ne quitte jamais le site. L'intégration demande quelques jours, et le questionnaire reste le SAQ A.

// Le SDK du prestataire monte des champs isolés dans la page du marchand.
// Le numéro saisi ne touche jamais le serveur du marchand : il part chiffré
// vers le prestataire, qui renvoie un jeton utilisable côté serveur.
const champs = prestataire.fields({ locale: "fr", theme: "flat" })

champs.create("cardNumber").mount("#numero-carte")
champs.create("expiryDate").mount("#expiration")
champs.create("cvv").mount("#cryptogramme")

document.querySelector("#payer").addEventListener("click", async () => {
  const { token, error } = await champs.tokenize()
  if (error) return afficherErreur(error.message)
  // Seul le jeton part vers le serveur du marchand, jamais le numéro.
  await fetch("/api/paiement", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ token, montant: 4280, devise: "EUR" }),
  })
})

Ce que les champs hébergés permettent

• Dessiner la page au pixel près autour des champs, dont les styles sont injectés
• Rester au questionnaire SAQ A, le numéro ne transitant que par les cadres du prestataire
• Supprimer la redirection, et avec elle la rupture de parcours
• Réunir portefeuilles et méthodes locales dans la même page

Ce qu'ils interdisent

• Lire ou modifier le contenu des champs, la validation se limitant aux événements du prestataire
• Modifier la structure interne des champs, dont le remplissage automatique dépend
• Échapper aux exigences PCI 6.4.3 et 11.6.1 sur l'inventaire des scripts de la page
• Router la même saisie vers plusieurs prestataires : le champ appartient à celui qui le sert

L'isolation des champs laisse la page qui les accueille sous la responsabilité du marchand. Les exigences 6.4.3 et 11.6.1 portent précisément sur cette page, et la dernière section du dossier les détaille. Le profil de la méthode les range parmi ce qu'elle n'écarte pas, au même titre que l'impossibilité de router une même saisie vers deux prestataires.

Le composant prêt à poser

Le composant prêt à poser est un élément d'interface complet, fourni par le prestataire et inséré dans la page du marchand. Adyen le nomme Drop-in, Stripe le nomme Payment Element. Il porte le formulaire, les portefeuilles, les méthodes locales et l'authentification, et il se thème. La disposition, elle, reste celle du prestataire. L'intégration demande un à deux jours, et le questionnaire reste le SAQ A.

Ce que le composant permet

• Déployer toutes les méthodes, cartes, portefeuilles, iDEAL ou Pix, dans un seul composant
• Hériter des optimisations de conversion du prestataire, à commencer par l'ordre des méthodes
• Thémer couleurs, arrondis et polices sans reprendre chaque champ
• Laisser l'authentification forte s'orchestrer seule

Ce qu'il interdit

• Sortir de la structure du composant, dont la disposition est imposée
• Construire des parcours très particuliers, comme certains parcours entre entreprises
• Mêler plusieurs prestataires dans le même composant
• Maîtriser la formulation des messages d'erreur

L'interface serveur à serveur

L'interface serveur à serveur fait collecter le numéro de carte par le marchand, qui le transmet ensuite à son prestataire. Le montage est réservé aux grands marchands, aux orchestrateurs et aux prestataires eux-mêmes certifiés. Les serveurs du marchand entrent alors dans l'environnement des données de carte. Le contrôle y est total. Le questionnaire passe d'une trentaine de questions à plusieurs centaines, et l'intégration se compte en semaines, audit compris.

Ce que l'interface permet

• Maîtriser l'ensemble du parcours, les champs et les applications mobiles propriétaires
• Router chaque opération vers l'acquéreur le mieux placé, en cascade si besoin
• Tokeniser dans un coffre propre au marchand, donc portable
• Employer directement les jetons de réseau et régler finement les nouvelles tentatives

Ce qu'elle interdit

• Échapper au niveau complet de PCI DSS : audit annuel, scans trimestriels, test d'intrusion
• Stocker le cryptogramme visuel, interdit dans tous les cas
• Aller vite : la conformité et la sécurité deviennent un investissement permanent
• Reporter la responsabilité sur le prestataire en cas de fuite, l'environnement des données étant celui du marchand

Cette charge achète des libertés que les quatre autres montages refusent. Le marchand route chaque opération vers l'acquéreur le mieux placé, en cascade lorsque le premier refuse. Il conserve ses jetons dans un coffre qui lui appartient, ce qui rend le portefeuille de cartes enregistrées transportable d'un prestataire à l'autre. Les jetons de réseau et le réglage des nouvelles tentatives lui reviennent également.

Prestataires proposant couramment ce montageAdyenCHCheckout.comWorldlineStripe

Le lien de paiement

Le lien de paiement se passe d'intégration. Aucun développement n'est requis. Le marchand engendre un lien depuis l'interface de son prestataire, puis l'envoie au client, qui règle sur une page entièrement hébergée. La mise en œuvre est immédiate, et le questionnaire reste le SAQ A. Le montage sert les ventes sur devis, les encaissements par téléphone et les échanges entre entreprises, des situations où aucun panier en ligne n'existe.

Ce que le lien permet

• Encaisser sans site, sur devis, par téléphone ou entre entreprises
• Suivre chaque créance, un lien correspondant à une facture
• Proposer carte, portefeuilles et virement sur la même page
• Automatiser l'envoi et les relances par interface de programmation

Ce qu'il interdit

• S'intégrer au parcours de vente en ligne, le paiement se déroulant hors du site
• Personnaliser au-delà du logo
• Enregistrer la carte pour un achat ultérieur, faute de session client
• Traiter de gros volumes sans automatisation

L'inventaire des scripts de la page

Les exigences 6.4.3 et 11.6.1 de PCI DSS v4.0.x portent sur les scripts de la page de paiement, et elles sont obligatoires depuis le 31 mars 2025. La première couvre l'inventaire, la justification et l'intégrité de tous les scripts servis sur cette page. La seconde couvre la détection des altérations, sur les en-têtes de sécurité comme sur le contenu tel que le navigateur le reçoit. Les deux se répondent, la prévention limitant ce qui peut s'exécuter et la détection attrapant ce qui a échappé.

Ces exigences répondent au skimming web, dont les attaques dites Magecart sont la forme la plus connue. L'injection vise la page du marchand, pas le prestataire. L'inventaire porte donc sur la page que sert le marchand lui-même. Un cadre servi par le prestataire ne met pas cette page à l'abri, puisqu'elle peut être détournée pour superposer un faux formulaire par-dessus les champs légitimes.

Les quatre montages légers déplacent la collecte du numéro chez le prestataire. Ils ne déplacent pas la page qui l'accueille, servie par le marchand et surveillée par lui. L'arbitrage se referme donc sur une asymétrie. Le périmètre PCI se réduit ; la surveillance de la page demeure.

Qui porte l'authentification forte

L'authentification forte du porteur se déroule pendant l'autorisation, et le montage détermine qui l'orchestre. La question compte au moins autant que le périmètre de conformité : le protocole 3-D Secure suppose de gérer un aller-retour vers l'émetteur, une reprise de la transaction au retour, et le cas où l'écran d'authentification n'aboutit pas. Quatre des cinq méthodes en déchargent le marchand.