Qu'est-ce que la tokenisation des paiements ?

La tokenisation des paiements remplace un numéro de carte par une valeur de substitution, un jeton, qui n'a aucune relation mathématique avec la carte. Un coffre-fort conserve la correspondance entre les deux. Le commerçant ne stocke que le jeton et le présente pour facturer à nouveau le client, ainsi les données de carte ne résident jamais dans les systèmes du commerçant, tout en permettant la facturation récurrente.

Quelle est la différence entre la tokenisation et le chiffrement ?

Le chiffrement transforme un numéro de carte en texte chiffré que toute personne détenant la clé peut inverser, ainsi la protection voyage avec les données et dépend de la gestion des clés. La tokenisation substitue une valeur sans rapport et conserve la correspondance dans un coffre-fort séparé, ainsi une base de données de jetons volée ne révèle rien d'elle-même. Le chiffrement protège les données en transit ; la tokenisation les retire entièrement de vos systèmes.

La tokenisation des paiements réduit-elle le périmètre PCI ?

Oui, si le numéro de carte n'atteint jamais vos serveurs. Les systèmes ne contenant que des jetons sont hors périmètre car les jetons ne sont pas des données de titulaire de carte, c'est pourquoi les champs hébergés, les iframes et la tokenisation côté client existent. Le périmètre ne disparaît pas : la page de paiement reste la vôtre, et les exigences 6.4.3 et 11.6.1 de PCI DSS v4 couvrent la gestion des scripts et la détection d'altération sur cette page.

Les jetons de paiement peuvent-ils être transférés à un autre fournisseur ?

Pas directement. Un jeton de passerelle n'a pas de sens en dehors du coffre-fort qui l'a émis, donc la migration nécessite un transfert de coffre-fort à coffre-fort dans lequel le fournisseur actuel exporte les données de carte sous-jacentes vers le nouveau, dans des conditions conformes à la norme PCI. Les deux parties peuvent le faire, mais le fournisseur sortant n'a aucune incitation commerciale, donc le droit d'exportation doit figurer dans le contrat avant que vous ne le signiez.

La tokenisation des paiements est-elle identique à un jeton de réseau ?

Un jeton de réseau est un type de jeton de paiement, émis par Visa, Mastercard ou American Express plutôt que par un fournisseur de paiement. C'est le seul type qui reste valide lorsque la carte est réémise et le seul type qui peut être transféré à un autre processeur. Un jeton de coffre-fort de passerelle est le type le plus courant et ne possède aucune de ces propriétés.

De quoi d'autre avez-vous besoin, en dehors du jeton, pour facturer un abonnement ?

Vous avez besoin de l'enregistrement du consentement : ce à quoi le client a consenti, quand, la version des conditions acceptées, le type de transaction, et l'identifiant de transaction réseau renvoyé par l'autorisation initiale initiée par le client. Les paiements ultérieurs initiés par le commerçant font référence à cet identifiant pour être reconnus comme des continuations autorisées. La migration de jetons sans cela fait généralement chuter les taux d'autorisation dès le premier cycle après le transfert.

Paiements

Tokenisation des paiements

La tokenisation des paiements consiste à remplacer les détails de la carte par un jeton de référence afin qu'un commerçant puisse débiter une information d'identification stockée de manière répétée sans détenir le numéro de carte lui-même.

C'est ce qui rend la facturation récurrente possible sans que chaque commerçant ne devienne un coffre-fort de cartes relevant du périmètre PCI. Le jeton n'a pas de sens en dehors du contexte qui l'a émis, ce qui constitue sa propriété de sécurité.

Cette même propriété est aussi commerciale. Un jeton émis par une plateforme ou un fournisseur d'applications ne peut généralement pas être utilisé par quelqu'un d'autre, donc quiconque le détient détient votre capacité à facturer. Établissez la portabilité par écrit avant d'avoir une base d'abonnés suffisamment importante pour que cela compte.

Ce qui est remplacé, et ce qu'est réellement un jeton

Ce qui est protégé est le numéro de compte principal — le PAN, le long numéro figurant au recto de la carte — ainsi que la date d'expiration et, au moment de la saisie, le code de sécurité. Ces trois valeurs sont des données de titulaire de carte, et leur détention entraîne une entreprise dans la partie coûteuse de la norme PCI DSS.

Un jeton remplace le PAN par une valeur qui n'a aucune relation mathématique avec celui-ci. C'est la distinction avec le chiffrement, et ce n'est pas une distinction pédante : un texte chiffré peut être inversé par quiconque obtient la clé, tandis qu'un jeton ne peut être résolu que par le coffre-fort qui détient le mappage. Le vol d'une base de données de jetons ne donne rien sans compromettre également le coffre-fort, qui est un système distinct sous un contrôle distinct.

Les jetons se présentent sous deux formes et sont constamment confondus. Les jetons à format conservé ressemblent à des numéros de carte — même longueur, passant la même somme de contrôle — afin qu'ils puissent transiter par des systèmes conçus pour transporter un PAN. Les jetons opaques sont des identifiants arbitraires, les chaînes de caractères de style `tok_` et `pm_` familières des API modernes, et ils ne peuvent se faire passer pour une carte nulle part.

La confusion la plus importante concerne l'usage unique par rapport à l'usage multiple. La valeur qu'un champ de paiement côté client transmet à votre serveur est généralement un jeton à usage unique : il existe pour transporter une saisie de carte du navigateur au processeur sans toucher votre infrastructure, et il expire à la première utilisation. La valeur que vous stockez pour la facturation future est un objet entièrement différent — une référence de coffre-fort durable, créée délibérément, qui survit pour être débitée à nouveau. Traiter le premier comme le second est la façon dont les équipes découvrent lors du premier renouvellement qu'elles n'ont jamais rien enregistré.

Trois types de jetons, et ils ne sont pas interchangeables

Le terme couvre plusieurs arrangements qui diffèrent selon qui détient le mappage, et ce seul fait détermine tout concernant la portabilité, la résilience et ce qui se passe lorsque la carte est réémise.

Un jeton de coffre-fort de passerelle ou de PSP est le cas le plus courant et le plus confiné : le mappage réside dans la base de données d'un seul fournisseur et n'a aucun sens en dehors de celle-ci. Un fournisseur de services de jetons indépendant a la même forme avec le coffre-fort sous un toit différent, choisi précisément pour que le coffre-fort ne soit pas la propriété de la partie que vous pourriez vouloir quitter. Un jeton de réseau, décrit dans sa propre entrée, est émis par le réseau de cartes et est le seul des trois que les réseaux eux-mêmes maintiennent.

Type	Qui détient le mappage	Survit à la réémission de la carte	Utilisable par un autre processeur
Jeton de paiement à usage unique	Le processeur, brièvement	Non applicable — il expire à l'utilisation	Non
Jeton de coffre-fort de passerelle ou de PSP	Le fournisseur de paiement	Non, sans un service de mise à jour de compte	Non — un transfert de coffre-fort est requis
Fournisseur de services de jetons indépendant	Un fournisseur de coffre-fort avec lequel vous contractez directement	Non, sans un service de mise à jour de compte	Oui — c'est la raison de l'utiliser
Jeton de réseau	Le réseau de cartes	Oui, automatiquement	Dépend de l'arrangement du demandeur de jeton

Où réside le mappage, et ce qui en découle

Comment cela réduit le périmètre PCI, et où le périmètre ne disparaît pas

Le périmètre PCI DSS suit les données des titulaires de carte. Les systèmes qui stockent, traitent ou transmettent un PAN sont dans le périmètre ; les systèmes qui ne détiennent que des jetons ne le sont pas, car un jeton n'est pas une donnée de titulaire de carte. La tokenisation est donc une technique de réduction de périmètre avant toute autre chose.

La réduction ne se matérialise que si le numéro de carte n'atteint véritablement jamais vos serveurs. C'est ce que les champs hébergés, un iframe du processeur, la tokenisation côté client et les redirections complètes visent tous à réaliser. Une intégration qui envoie la carte à votre backend et la tokenise là-bas a déplacé le stockage hors du périmètre tout en laissant le traitement et la transmission fermement à l'intérieur, ce qui représente une économie bien moindre que ce que suggère le diagramme d'architecture.

Ce qui subsiste est la page de paiement elle-même. Vous contrôlez toujours la page qui charge le champ de paiement, et un script injecté dans cette page peut lire une carte avant même que le processeur ne la voie. PCI DSS v4 aborde cela directement avec des exigences couvrant la gestion des scripts sur les pages de paiement et la détection d'altération sur ces pages — 6.4.3 et 11.6.1. Aucune de ces exigences n'est levée par la tokenisation.

Le résumé honnête est que la tokenisation fait passer un commerçant de la preuve de la sécurité d'un coffre-fort de cartes à la preuve de l'intégrité d'une page de paiement. C'est un bien meilleur compromis, et ce n'est pas la même chose que de n'avoir aucune obligation.

Le piège de la portabilité : un jeton de passerelle ne se déplace pas

La propriété qui rend un jeton sûr est qu'il n'a pas de sens en dehors du contexte qui l'a émis. Cette propriété ne fait pas de distinction entre un attaquant et votre prochain fournisseur de paiement.

La migration d'un carnet d'informations d'identification stockées nécessite donc un transfert de coffre-fort à coffre-fort : le fournisseur sortant exporte les données de carte dans des conditions conformes à la norme PCI vers le fournisseur entrant, qui les re-tokenise. Il s'agit d'une procédure bien établie, les deux parties peuvent le faire, et elle nécessite la coopération d'une entreprise dont l'intérêt commercial est servi par l'absence de transfert. L'alternative est de demander à chaque abonné actif de ressaisir une carte, et une part significative d'entre eux ne le fera tout simplement pas — ce n'est pas de l'attrition que vous récupérez, c'est de l'attrition que vous avez causée.

La clause à obtenir est un droit d'exporter les informations d'identification stockées vers un fournisseur alternatif désigné, sur demande, dans un délai spécifié, à un coût spécifié. Il ne coûte rien de négocier avant d'avoir une base d'abonnés et il est presque impossible de l'obtenir une fois que la base existe.

Stocker une information d'identification pour la facturation récurrente

Un jeton seul ne suffit pas pour facturer à nouveau un client. Ce qui rend un débit ultérieur valide est l'enregistrement du consentement qui l'accompagne, et cet enregistrement comporte plusieurs parties qu'une migration naïve laisse de côté.

L'information d'identification stockée nécessite le mandat : ce à quoi le client a consenti, quand il a consenti, la version des conditions qu'il a acceptées, ainsi que la cadence et le montant auxquels il a consenti. Elle nécessite le type de transaction — récurrente, à tempérament ou non planifiée — car les réseaux les traitent différemment. Et elle nécessite l'identifiant de transaction réseau renvoyé par l'autorisation initiale initiée par le client, que les débits ultérieurs initiés par le commerçant doivent référencer pour être reconnus comme des continuations autorisées plutôt que comme des débits non rattachés à une carte.

Ce dernier champ est celui qui disparaît. Une migration qui déplace les jetons mais pas les identifiants de transaction réseau d'origine empêche le processeur récepteur de présenter les renouvellements comme des transactions valides initiées par le commerçant, et le résultat est un taux d'autorisation qui chute dès le premier cycle de facturation après le transfert, pour des raisons que personne n'avait anticipées dans le plan de projet.

Outre l'identifiant lui-même, il est utile de conserver ce que vous êtes autorisé à afficher et à utiliser pour la prédiction : la marque de la carte, les quatre derniers chiffres et la date d'expiration. Ce sont ces informations qui permettent à un client de reconnaître quelle carte est enregistrée, et qui vous permettent d'identifier les identifiants qui expireront avant le prochain renouvellement et de contacter ces clients avant que le paiement n'échoue.

Questions fréquentes

Qu'est-ce que la tokenisation des paiements ?: La tokenisation des paiements remplace un numéro de carte par une valeur de substitution, un jeton, qui n'a aucune relation mathématique avec la carte. Un coffre-fort conserve la correspondance entre les deux. Le commerçant ne stocke que le jeton et le présente pour facturer à nouveau le client, ainsi les données de carte ne résident jamais dans les systèmes du commerçant, tout en permettant la facturation récurrente.
Quelle est la différence entre la tokenisation et le chiffrement ?: Le chiffrement transforme un numéro de carte en texte chiffré que toute personne détenant la clé peut inverser, ainsi la protection voyage avec les données et dépend de la gestion des clés. La tokenisation substitue une valeur sans rapport et conserve la correspondance dans un coffre-fort séparé, ainsi une base de données de jetons volée ne révèle rien d'elle-même. Le chiffrement protège les données en transit ; la tokenisation les retire entièrement de vos systèmes.
La tokenisation des paiements réduit-elle le périmètre PCI ?: Oui, si le numéro de carte n'atteint jamais vos serveurs. Les systèmes ne contenant que des jetons sont hors périmètre car les jetons ne sont pas des données de titulaire de carte, c'est pourquoi les champs hébergés, les iframes et la tokenisation côté client existent. Le périmètre ne disparaît pas : la page de paiement reste la vôtre, et les exigences 6.4.3 et 11.6.1 de PCI DSS v4 couvrent la gestion des scripts et la détection d'altération sur cette page.
Les jetons de paiement peuvent-ils être transférés à un autre fournisseur ?: Pas directement. Un jeton de passerelle n'a pas de sens en dehors du coffre-fort qui l'a émis, donc la migration nécessite un transfert de coffre-fort à coffre-fort dans lequel le fournisseur actuel exporte les données de carte sous-jacentes vers le nouveau, dans des conditions conformes à la norme PCI. Les deux parties peuvent le faire, mais le fournisseur sortant n'a aucune incitation commerciale, donc le droit d'exportation doit figurer dans le contrat avant que vous ne le signiez.
La tokenisation des paiements est-elle identique à un jeton de réseau ?: Un jeton de réseau est un type de jeton de paiement, émis par Visa, Mastercard ou American Express plutôt que par un fournisseur de paiement. C'est le seul type qui reste valide lorsque la carte est réémise et le seul type qui peut être transféré à un autre processeur. Un jeton de coffre-fort de passerelle est le type le plus courant et ne possède aucune de ces propriétés.
De quoi d'autre avez-vous besoin, en dehors du jeton, pour facturer un abonnement ?: Vous avez besoin de l'enregistrement du consentement : ce à quoi le client a consenti, quand, la version des conditions acceptées, le type de transaction, et l'identifiant de transaction réseau renvoyé par l'autorisation initiale initiée par le client. Les paiements ultérieurs initiés par le commerçant font référence à cet identifiant pour être reconnus comme des continuations autorisées. La migration de jetons sans cela fait généralement chuter les taux d'autorisation dès le premier cycle après le transfert.