Le modèle card-on-file permet à un marchand de stocker les informations de carte d'un client pour les utiliser lors de transactions futures sans que le client ait à ressaisir ses données. C'est la base des abonnements, des paiements récurrents et des achats en un clic. Mais ce modèle soulève des obligations PCI DSS spécifiques — que la tokenisation permet de gérer sans stocker un seul PAN.
Qu'est-ce que le card-on-file et pourquoi est-il risqué ?
Le card-on-file (COF) désigne toute situation où un marchand conserve les données de carte d'un titulaire dans ses systèmes pour les utiliser lors d'une ou plusieurs transactions futures. Cela inclut les abonnements mensuels, les paiements en un clic sur une plateforme e-commerce, les applications de livraison avec carte mémorisée, et tout modèle freemium avec facturation différée.
Le problème fondamental du card-on-file traditionnel est le stockage du PAN. Stocker un numéro de carte complet dans une base de données fait entrer cette base de données — et tous les systèmes qui y ont accès — dans le périmètre CDE PCI DSS. Cela multiplie les obligations de conformité et crée un risque de sécurité majeur : si votre base de données est compromise, tous les PAN stockés sont exposés.
Les réseaux de paiement (Visa, Mastercard) ont également renforcé leurs exigences concernant le card-on-file : depuis 2019, toutes les transactions COF initiées par le marchand doivent être identifiées comme telles et comporter un indicateur spécifique dans l'autorisation. La gestion de ces indicateurs est simplifiée lorsqu'elle est déléguée à un prestataire de tokenisation certifié.
Comment fonctionne la tokenisation card-on-file
Avec la tokenisation COF, le processus est le suivant : lors du premier paiement (ou de l'enregistrement de la carte), le client saisit ses données de carte dans une iFrame ou un formulaire sécurisé hébergé par PCI Proxy EU. Le PAN est transmis directement au vault de tokenisation, qui génère un token COF persistant et le renvoie à votre application.
Votre application stocke uniquement ce token dans votre base de données clients, associé au profil utilisateur. Lors des transactions futures (renouvellement d'abonnement, achat récurrent), votre serveur soumet le token à PCI Proxy EU, qui récupère le PAN correspondant dans le vault sécurisé et initie l'autorisation auprès de l'acquéreur. Vos serveurs ne voient jamais le PAN, ni lors de l'enregistrement, ni lors des transactions ultérieures.
Un token COF peut avoir différentes durées de vie selon votre configuration : jusqu'à l'expiration de la carte, pour une durée contractuelle fixe, ou indéfiniment jusqu'à révocation par le client. PCI Proxy EU gère également l'Account Updater — le service qui met automatiquement à jour les données de carte lorsqu'une carte expire ou est renouvelée, évitant ainsi les échecs de paiement récurrents.
Obligations PCI DSS spécifiques au card-on-file
Les marchands card-on-file sont soumis aux exigences les plus strictes de PCI DSS en matière de stockage des données. L'exigence 3 impose que seul le PAN tronqué (les six premiers et quatre derniers chiffres) peut être stocké dans les systèmes lisibles par les humains, et que si un PAN complet doit être conservé, il doit être protégé par un chiffrement fort avec gestion sécurisée des clés.
L'exigence 3.3 interdit formellement le stockage des données d'authentification sensibles après autorisation — CVV, données de piste magnétique, PIN — même sous forme chiffrée. L'exigence 3.4 impose la protection du PAN partout où il est stocké. Pour les marchands COF qui traitent des millions de cartes enregistrées, ces obligations représentent un investissement de conformité considérable.
Avec la tokenisation, vous remplacez le PAN stocké par un token, ce qui vous permet de répondre à ces exigences sans infrastructure de chiffrement complexe. Les tokens stockés dans votre base de données ne sont pas des données de carte — ils ne tombent pas dans le périmètre CDE, et leur stockage ne génère pas d'obligation PCI DSS spécifique à leur égard.
Gestion des tokens et conformité RGPD
Les tokens COF créent une intersection intéressante entre PCI DSS et RGPD. Le token lui-même est une donnée pseudonymisée au sens du RGPD : il identifie indirectement une personne (via la correspondance avec son compte client) mais ne contient pas de données de carte directement exploitables. Cette pseudonymisation facilite la mise en conformité RGPD pour les données de paiement.
Lorsqu'un client exerce son droit à l'effacement (article 17 RGPD), vous pouvez supprimer le token de votre base de données et demander à PCI Proxy EU de supprimer le PAN correspondant dans le vault. Cette opération garantit que les données de carte du client sont définitivement effacées de tous les systèmes, satisfaisant l'obligation RGPD d'effacement complet.
La gestion des consentements est également simplifiée : le token COF peut être associé à la date et au type de consentement obtenu lors de l'enregistrement de la carte, permettant de documenter et de prouver que le client a accepté l'utilisation de sa carte pour des paiements récurrents futurs. Cette traçabilité est exigée par les réseaux de paiement et s'aligne avec les obligations RGPD de documentation du consentement.
Implémentation pratique avec PCI Proxy EU
L'intégration du card-on-file avec PCI Proxy EU commence par la mise en place de l'iFrame d'enregistrement de carte sur votre page de profil client ou de tunnel d'abonnement. L'iFrame est entièrement personnalisable visuellement pour s'intégrer dans votre design, mais gère la saisie et la transmission des données de carte de façon isolée de votre application.
Une fois l'iFrame configurée, votre backend reçoit un token COF unique via webhook ou réponse API synchrone. Ce token est stocké dans votre table clients ou votre système d'abonnement. Pour les paiements récurrents, votre système de facturation soumet simplement ce token à l'API PCI Proxy EU avec le montant à débiter et les identifiants acquéreur — aucune autre donnée de carte n'est requise.
PCI Proxy EU supporte les principaux acquéreurs et PSP européens, ce qui vous permet de traiter les transactions COF via votre acquéreur préféré sans changer votre logique métier. Si vous changez d'acquéreur, les tokens existants restent valides et peuvent être utilisés avec le nouvel acquéreur — c'est l'un des grands avantages de la tokenisation par rapport aux tokens natifs des acquéreurs.
Réduire le taux d'échec des paiements récurrents
L'un des défis majeurs du card-on-file est la gestion des cartes expirées ou renouvelées. Selon les études du secteur, entre 15 et 25 % des cartes enregistrées sont remplacées chaque année en raison d'expiration, de fraude ou de réémission. Sans mise à jour automatique, ces renouvellements génèrent des échecs de paiement et du churn involontaire.
PCI Proxy EU intègre un service d'Account Updater qui interroge périodiquement les réseaux de paiement pour identifier les cartes renouvelées et mettre à jour automatiquement les informations dans le vault. Le token COF reste identique dans votre système, mais il est désormais associé aux nouvelles données de carte. Vous n'avez rien à faire — vos paiements récurrents continuent sans interruption.
Gérez vos paiements récurrents sans stocker de PAN : découvrir PCI Proxy EU.