Numéros de carte de test par réseau : Visa, Mastercard et plus

Prenez deux cartes de paiement de réseaux différents et les numéros ne se ressemblent pas. L’une peut compter seize chiffres groupés par quatre, une autre quinze chiffres groupés quatre, six et cinq, et les chiffres finaux obéissent à la même somme de contrôle alors que les longueurs ne concordent pas du tout. Construire des numéros de carte de test par réseau consiste à travailler délibérément avec ces différences, car une intégration qui ne voit jamais qu’une seule marque est une intégration qui n’a jamais exécuté la plupart de son propre code.

Cet article expose les différences qui comptent, montre comment lire les plages publiées, et explique pourquoi un numéro au bon préfixe n’appartient toujours à personne.

Chaque réseau a son propre plan de numérotation

Un réseau de cartes enregistre les plages de préfixes émetteurs qu’il reconnaîtra et le nombre de chiffres qu’une carte de chaque plage portera. C’est cet enregistrement qui permet à un terminal de paiement de décider, sans aucun appel réseau, à quelle marque appartient une carte et si le numéro est même plausible.

Le résultat est un petit ensemble de familles plutôt qu’une forme universelle unique. Certains réseaux n’utilisent presque exclusivement qu’une longueur ; d’autres prennent en charge plusieurs longueurs selon les niveaux de produit ou les régions. Les codes de sécurité diffèrent aussi, à la fois par le nombre de chiffres qu’ils contiennent et par le côté de la carte où ils sont imprimés. Un jeu de test qui ignore ces différences passera la revue et échouera en production.

Comment choisir un préfixe pour un cas de test ?

Partez à rebours de la branche que vous voulez exercer. Si votre formulaire change de disposition selon la marque détectée, il vous faut au moins un numéro par marque déclenchant une disposition distincte. Si votre validation a une branche pour un numéro à quinze chiffres, il vous faut un numéro de cette longueur. Si votre paiement gère un code de sécurité à quatre chiffres, il vous faut une carte dont le réseau en utilise un.

Vérifiez ensuite que le préfixe choisi est publié plutôt qu’inventé. Utiliser une plage qu’aucun réseau n’a enregistrée produit un numéro que votre propre détection de préfixe rejettera, ce qui fait ressembler le test à un échec de la logique de détection plutôt qu’à un échec de la fixture.

Un raccourci pratique consiste à générer un numéro pour chaque marque que vous prenez en charge et à conserver l’ensemble comme une fixture nommée, afin que le jeu puisse être régénéré chaque fois qu’une marque est ajoutée ou qu’une règle de longueur change.

Les plages publiées en un coup d’œil

Le tableau suivant résume les plages de préfixes publiquement documentées et les formes qui les accompagnent. Il décrit des plans de numérotation, pas des produits ni des émetteurs particuliers.

Deux mises en garde accompagnent le tableau. Les plages sont enregistrées par les réseaux et changent occasionnellement, donc un détecteur devrait être écrit pour tolérer des ajouts plutôt que de traiter la liste comme définitive. Et la longueur est une propriété de la plage, pas de la marque dans son ensemble : une règle qui dit qu’un réseau particulier a toujours seize chiffres finira par être fausse.

Pourquoi la longueur du code de sécurité diffère-t-elle aussi ?

Le fait qu’American Express utilise quatre chiffres n’est pas une amélioration de sécurité par rapport à trois ; c’est simplement la façon dont la spécification de ce réseau est écrite. L’effet pratique retombe sur le formulaire, qui doit savoir combien de caractères accepter.

Si votre interface propose un champ unique avec un maximum fixe de trois caractères, un code American Express sera silencieusement tronqué, et le client verra un échec qui n’a aucun sens pour lui. L’approche robuste consiste à accepter la longueur attendue du réseau une fois la marque connue, et à autoriser un maximum légèrement généreux lorsqu’elle ne l’est pas, afin qu’un collage ne perde jamais un caractère dont l’utilisateur aura besoin.

Un préfixe correspondant signifie-t-il que le numéro est réel ?

Non. Le préfixe vous dit à quelle plage un numéro prétend appartenir, et rien de plus. N’importe quelle chaîne de chiffres commençant par une plage enregistrée peut être complétée par des chiffres du milieu arbitraires et un chiffre final calculé, produisant quelque chose que chaque contrôle local acceptera.

Il en va de même pour les données générées : un numéro est structurellement valide et n’a jamais été émis à personne. C’est une propriété sur laquelle il vaut la peine de compter plutôt qu’une limitation, car cela signifie que la valeur peut être utilisée dans une démonstration ou une fixture sans aucun risque qu’elle résolve vers un compte réel. Cela signifie aussi qu’un contrôle de format réussi ne devrait jamais être décrit à un utilisateur comme la confirmation que sa carte existe.

Pour les développeurs : construire une matrice de test par réseau

Une matrice de test transforme une liste de marques en une liste de décisions, et il vaut la peine de l’écrire dans un tableau à quatre colonnes : la marque, la plage de préfixes utilisée, le résultat de détection attendu, et le comportement du formulaire que vous en attendez.

À partir de là, trois règles gardent la matrice utile. Incluez exactement un numéro par comportement distinct plutôt que beaucoup de numéros par marque, car des fixtures redondantes ajoutent de la maintenance sans ajouter de couverture. Notez la longueur attendue pour chaque entrée, afin qu’une modification d’une règle de longueur apparaisse comme un test en échec plutôt que comme un assouplissement inaperçu. Et conservez au moins un numéro dont le préfixe n’appartient à aucune plage que vous prenez en charge, afin que le chemin de la marque inconnue soit exercé plutôt que supposé.

Surveillez la fonction de détection elle-même. Les implémentations qui ne comparent que le premier chiffre regroupent toutes les cartes bancaires ensemble, et celles qui testent les plages dans le mauvais ordre peuvent laisser une plage étroite être avalée par une plus large. Ces deux bugs sont invisibles jusqu’à ce qu’une carte particulière arrive, ce qui est exactement ce que la matrice existe pour prévenir.

Enfin, rappelez-vous que la détection de format n’est pas une autorisation. Une matrice de test est une affirmation sur votre propre code, et aucun agencement de préfixes ne vous dira si une carte est valide pour un paiement. Le parcours de validation couvre la place de la détection dans la séquence des contrôles, et le guide du format explique comment le préfixe se rapporte au reste du numéro.

Produire une carte par réseau

Pour construire le jeu de fixtures, ouvrez le générateur de numéros de carte, choisissez un réseau et copiez le résultat ; répétez pour chaque marque que vous prenez en charge, puis stockez la collection avec une note indiquant quel comportement chaque entrée est censée déclencher. Générer plutôt que recopier des plages depuis la documentation garde le lot cohérent en interne et vous donne une quantité qui peut être étendue chaque fois qu’un nouveau moyen de paiement est ajouté.

Les notes PCI DSS méritent d’être lues avant que ce jeu ne soit committé dans un espace partagé, et le guide des cartes de test des prestataires explique quand un numéro de bac à sable scénarisé est un meilleur choix qu’un numéro synthétique.

Étapes suivantes

Dressez la matrice, générez une carte par comportement distinct, et ajoutez une fixture pour une plage que vous ne prenez délibérément pas en charge afin que le chemin inconnu reste couvert. Passez ensuite la fonction de détection en revue par rapport au tableau, en commençant par les plages les plus étroites, pour confirmer qu’aucune branche n’est inatteignable.