Déplacer les cartes enregistrées entre processeurs

Il n'y a pas de règle de portabilité à invoquer

Les commerçants qui quittent un fournisseur présument souvent qu'une règle de réseau leur donne droit à leur coffre. Les règles fondamentales de Visa et les règles sur les produits et services, dans l'édition publique du 18 avril 2026, ne traitent pas du tout du transfert d'identifiants enregistrés entre fournisseurs. Ce silence est la conclusion. Le levier est contractuel, ce qui signifie qu'il n'existe que si vous l'avez négocié, et le moment de le négocier est avant l'intégration plutôt qu'à l'annulation. Demandez les conditions de sortie par écrit : si le coffre est exportable sur demande, vers quelles destinations, avec quel préavis, à quel coût, dans quel format, et avec quelle assistance pour rétablir les identifiants de l'autre côté. Un fournisseur qui refuse de l'inscrire dans l'entente vous a déjà dit quelle sera la réponse plus tard.

Ce qui se trouve réellement dans un coffre

Le PCI Security Standards Council décrit la tokenisation comme un processus par lequel le numéro de compte principal est remplacé par une valeur de substitution appelée jeton, et distingue les jetons à usage unique, qui représentent habituellement une seule transaction, des jetons à usages multiples, qui représentent un NCP précis et associent toujours ce NCP à la même valeur de jeton à l'intérieur du système. « À l'intérieur du système » est l'expression clé. Un jeton à usages multiples n'a de sens qu'à l'intérieur du coffre qui l'a émis, alors ce qui se déplace lors d'une migration, ce ne sont pas les jetons, mais les numéros de compte sous-jacents, retokénisés par le fournisseur destinataire. Les jetons de réseau sont un objet encore différent : EMVCo décrit un jeton de paiement EMV comme une valeur alternative unique limitée dans la façon dont elle peut être utilisée, par exemple à un commerçant, un appareil ou un scénario de paiement précis. Demandez à votre fournisseur quel type vous détenez avant de présumer quoi que ce soit sur ce qu'une migration transférera. Notre guide sur la tokenisation présente la différence et les conditions de portée PCI en détail.

La chaîne d'identifiants doit survivre au déplacement

Le tableau 5-22 de Visa précise ce qui doit être vrai d'une transaction utilisant un identifiant enregistré, et chaque élément est une chose qu'une migration peut briser. Après qu'une entente avec le titulaire de carte a été complétée par écrit et avant que la première transaction ne survienne, le commerçant doit soumettre une demande d'autorisation pour le montant de la transaction, ou une vérification de compte si aucun paiement n'est requis, et ne doit pas stocker l'identifiant si cette demande n'est pas approuvée. Une transaction avec un identifiant enregistré doit utiliser le code de mode d'entrée PDV 10, et pour une transaction récurrente, par versements ou non planifiée avec identifiant enregistré, doit utiliser l'indicateur approprié dans le champ d'environnement PDV. Avant de traiter une transaction à l'initiative du titulaire de carte, le commerçant doit valider l'identité du titulaire de carte, par exemple avec un identifiant de connexion et un mot de passe. Et le montant d'autorisation ne doit pas dépasser le montant de la transaction individuelle. Un identifiant migré qui commence à être soumis sur la nouvelle plateforme sans que le mode d'entrée et l'indicateur soient correctement configurés n'est pas un problème de formatage — c'est un identifiant enregistré traité en dehors de la règle qui le permet, et cela se manifeste plus tard comme une qualité d'autorisation et une exposition aux litiges. Notre guide sur les cartes enregistrées couvre ces exigences de traitement en détail.

Votre entente avec le client disait déjà que cela arriverait

Le tableau 5-20 exige que l'entente avec le titulaire de carte divulgue le numéro de compte qui sera utilisé pour effectuer le paiement, quatre derniers chiffres seulement, « tel qu'il peut être mis à jour de temps à autre », et comment le titulaire de carte sera avisé de tout changement à l'entente. Il exige aussi du commerçant qu'il conserve ces renseignements pour la durée de l'entente et les fournisse au titulaire de carte ou à l'émetteur sur demande écrite. Une migration de coffre est un bon moment pour vérifier que ce que vous avez divulgué correspond à ce que vous faites, et que vous pouvez toujours produire l'entente pour un identifiant que vous avez pris il y a quatre ans sur une plateforme que vous êtes sur le point de désactiver. Dans la région Europe, il existe une exigence de temps additionnelle pour les transactions non planifiées avec identifiant enregistré : avis de tout changement au montant de la transaction ou à toute autre condition de l'entente au moins 2 jours ouvrables avant le changement.

La mise hors service de l'ancien coffre fait partie du travail

Les directives de portée du Conseil PCI précisent explicitement que tous les éléments du système et du processus de tokenisation, y compris la dé-tokenisation et le stockage du NCP, sont visés, et que pour que des systèmes soient traités comme hors de portée, l'une des conditions est que les systèmes qui détenaient auparavant des données de titulaire de carte aient été examinés pour confirmer que toutes les traces ont été supprimées de façon sécuritaire. Dans une migration, cette condition s'applique au fournisseur que vous quittez et à tout ce qui vous appartient et qui a touché l'exportation — serveurs intermédiaires, boîtes de courriel de soutien, une feuille de calcul que quelqu'un a créée pour rapprocher les comptes. Convenez par écrit, avant que l'exportation ne s'exécute, de qui supprime quoi et quand, et obtenez une confirmation par la suite plutôt que de le présumer. Les autres recommandations du Conseil pointent dans la même direction : limiter l'existence du NCP au point de capture et au coffre de données de carte, retirer toutes les données de titulaire de carte des systèmes source une fois tokénisées, et revoir votre utilisation des jetons dans le cadre de la validation annuelle de la portée PCI DSS.

Un exemple illustratif de ce qui passe entre les mailles

Exemple illustratif, avec des chiffres ronds fictifs. Une entreprise d'abonnement avec 5 000 cartes enregistrées migre ses coffres. L'exportation livre 5 000 registres; 200 ont expiré depuis le dernier débit réussi et 100 appartiennent à des comptes déjà annulés dans le système de facturation mais jamais supprimés du coffre. Le fournisseur destinataire retokénise les 5 000, et le premier cycle de facturation sur la nouvelle plateforme soumet 300 débits qui n'allaient jamais réussir. Rien de tout cela n'est un échec de migration — c'est un rapprochement qui était dû avant l'exportation. Comptez les identifiants que vous avez réellement l'intention de facturer, associez-les aux abonnements actifs, et traitez la différence comme un travail à faire d'abord. Attendez-vous à devoir rétablir, et non simplement rediriger, tout ce que le fournisseur destinataire ne peut pas accepter, et souvenez-vous de la règle du tableau 5-22 : si l'autorisation initiale ou la vérification de compte sur la nouvelle plateforme n'est pas approuvée, l'identifiant n'est pas stocké.