Un générateur de numéros de carte bancaire produit des numéros qui satisfont les règles structurelles qu’un formulaire de paiement vérifie, de sorte qu’un tunnel d’achat puisse être exercé sans qu’une vraie carte n’entre jamais en jeu. Le numéro n’est pas un identifiant, il n’est rattaché à aucun compte, et il n’autorisera rien — mais il passera les contrôles de format, les règles de préfixe émetteur et la clé de contrôle qu’un formulaire applique avant de transmettre quoi que ce soit.
Ce guide explique ce que signifient les parties d’un numéro de carte, pourquoi la clé de contrôle existe et ce qu’elle ne fait pas, pourquoi le code de sécurité et la date d’expiration doivent s’accorder avec le numéro dans un enregistrement de test, et où se situe la frontière entre un environnement de test et un environnement de données de titulaire de carte. À la fin, vous saurez ce qu’il faut vérifier dans un test de formulaire de paiement et ce qu’il faut tenir entièrement hors de votre dépôt.
Que signifient les parties d’un numéro de carte ?
Un numéro de carte est une chaîne de chiffres de longueur fixe composée de trois parties. Les premiers chiffres identifient l’émetteur et le réseau, les chiffres du milieu identifient le compte individuel au sein de cet émetteur, et le dernier chiffre est une valeur de contrôle calculée à partir de tous les autres. La longueur totale varie selon le réseau et selon le produit de carte, et un formulaire qui suppose une seule longueur rejettera des saisies valides.
Le numéro d’identification de l’émetteur est le préfixe, et c’est lui qui permet à un formulaire d’afficher le bon logo et d’appliquer les bonnes règles avant qu’une requête ne soit envoyée. Les préfixes des grands réseaux occupent des plages numériques distinctes, et ces plages sont publiées afin qu’un système puisse acheminer un numéro sans contacter quiconque. Lorsqu’un numéro généré porte un préfixe issu de la mauvaise plage, le formulaire le rejettera purement et simplement ou mal étiquettera le réseau dans l’interface.
La section du milieu est la partie qu’un générateur invente. Dans un enregistrement synthétique, elle ne porte aucun compte derrière elle, ce qui est précisément le but. Dans une vraie carte, elle pointe vers un compte précis chez un émetteur précis, ce qui est exactement pourquoi elle ne doit jamais apparaître dans une fixture de test.
Il en découle une conséquence pratique pour quiconque construit un générateur. Les numéros synthétiques les plus sûrs restent dans les plages numériques que les réseaux réservent aux tests, car ces plages sont définies de manière qu’aucun compte réel ne puisse y exister. Un générateur qui s’aventure dans tout l’espace des préfixes peut finir par produire une combinaison qui appartient à quelqu’un, et un numéro qui appartient à quelqu’un n’est plus une donnée de test, quelle que soit l’innocence de sa production.
Pourquoi la clé de contrôle existe et ce qu’elle prouve
Le dernier chiffre est calculé par une somme de contrôle pondérée sur les chiffres précédents, une règle généralement décrite comme l’algorithme de Luhn. Son but est de détecter les erreurs de transcription : un seul chiffre mal saisi, ou deux chiffres adjacents intervertis, produira presque toujours un numéro qui échoue au contrôle. L’article sur l’algorithme de Luhn déroule l’arithmétique étape par étape.
Ce que la clé de contrôle prouve est étroit, et la mal comprendre cause de vrais défauts. Elle prouve que les chiffres sont cohérents entre eux. Elle ne prouve rien sur l’existence du compte, sur l’activité de la carte, sur la disponibilité des fonds, ni sur le fait que le numéro appartienne à quiconque. Un formulaire qui traite une clé de contrôle valide comme une vérification de quoi que ce soit au-delà de l’arithmétique acceptera tous les numéros bien formés qu’un utilisateur peut produire en se trompant.
C’est la raison pour laquelle un numéro généré est si utile en test. Il porte exactement la propriété qu’un formulaire vérifie — la cohérence interne — et aucune des propriétés qu’un formulaire ne peut pas vérifier. L’écart entre ces deux ensembles est là où vivent la plupart des bugs de formulaire de paiement.
C’est aussi pourquoi les valeurs fictives échouent. Un champ rempli d’un chiffre répété, ou d’une courte séquence croissante, échouera à la clé de contrôle et n’atteindra donc jamais les chemins de code que vous voulez réellement tester. Un numéro de test utile est un numéro valide.
Pourquoi le code de sécurité et l’expiration doivent correspondre au numéro
Un enregistrement de carte est un petit ensemble de champs qui se contraignent mutuellement, et un formulaire de paiement acceptera des combinaisons qu’aucun émetteur n’émettrait jamais. La longueur du code de sécurité dépend du réseau, de sorte qu’un code à trois chiffres rattaché à un réseau qui en utilise quatre est une incohérence. La date d’expiration doit être dans le futur pour que la plupart des parcours l’acceptent, et le mois doit tomber dans les douze du calendrier.
Le fait que la carte soit un produit de débit ou de crédit influe aussi sur le comportement dans certains parcours. Certains tunnels d’achat les traitent de façon identique et d’autres appliquent des règles différentes, et une suite de tests qui n’exerce jamais qu’un seul type de produit ne découvrira pas la différence. Un générateur capable de produire les deux, avec des réseaux correspondant aux préfixes, vous donne la variété nécessaire pour trouver ces chemins.
Le préfixe émetteur et l’image de marque du réseau dans l’interface ont la même relation. Si le formulaire affiche le nom d’un réseau alors que le préfixe appartient à un autre, l’incohérence est un cas de test à part entière, et c’est un défaut sur lequel un testeur manuel tombe rarement parce qu’il tape les numéros qu’il connaît.
Les cartes de test officielles valent-elles mieux que les numéros générés ?
Les prestataires de paiement publient des numéros de carte de test pour leurs environnements bac à sable, et ces numéros sont le bon choix pour un usage précis : exercer le comportement du prestataire lui-même. Un numéro de test publié est lié à des résultats documentés — un paiement accepté, un paiement refusé, un code d’erreur précis — et reproduire ces résultats dépend de l’utilisation de ce numéro exact.
Les numéros générés servent un autre usage. Ils concernent les parties de la pile qui vous appartiennent : votre validation côté client, votre détection de préfixe, votre formatage, vos messages d’erreur, votre stockage et votre gestion des longueurs inhabituelles. Un bac à sable n’aura pas de résultat documenté pour un numéro qu’il n’a jamais vu, donc les numéros générés servent à tout ce qui se produit avant que la requête ne quitte votre application.
Les deux approches se combinent bien. Utilisez des numéros générés pour la large matrice de cas de validation, et un petit ensemble de numéros de prestataire publiés pour la poignée de tests d’intégration qui vérifient les réponses du prestataire. L’article sur les cartes de test Stripe couvre la seconde catégorie, et la liste de contrôle des tests de formulaire de paiement couvre la première.
Quel que soit votre choix, gardez les numéros dans le code de test et hors des fixtures qui atteignent un point de terminaison réel. Un numéro de bac à sable envoyé accidentellement à une passerelle de production sera rejeté, mais compter sur ce rejet comme filet de sécurité n’est pas un contrôle.
Une propriété supplémentaire mérite d’être conçue : une date d’expiration qui ne devient jamais obsolète. Une fixture avec une date d’expiration codée en dur décrira un jour une carte qui a expiré le mois dernier, et le test commencera à échouer pour une raison qui n’a rien à voir avec le changement à l’étude. Un générateur qui calcule l’expiration par rapport à la date du jour garde la fixture valide indéfiniment, et il retire toute une classe d’échecs déroutants de la suite.
Que signifie PCI DSS pour une entreprise sans vraies cartes
La norme de sécurité des données de l’industrie des cartes de paiement régit la façon dont les données de titulaire de carte sont stockées, traitées et transmises. Sa règle centrale est simple à énoncer et facile à sous-estimer : un environnement de test ne doit pas contenir de vrais numéros de carte. Ni dans une fixture, ni dans un script d’amorçage, ni dans un commentaire, ni dans un journal.
La raison est qu’un numéro de carte accompagné d’un nom et d’une date d’expiration constitue une donnée protégée, quel que soit l’environnement dans lequel il se trouve. Copier une ligne de production vers la préproduction crée un nouvel emplacement détenant des données de titulaire de carte, généralement avec des contrôles d’accès plus faibles et un historique de sauvegarde plus long. L’article sur les données de test PCI DSS examine les conséquences plus en détail.
Pour une équipe qui ne détient aucune vraie carte, la conformité est relativement simple. Si chaque numéro de l’environnement est synthétique et qu’aucune vraie carte ne peut y arriver, la question du périmètre se règle en grande partie d’elle-même. La discipline requise est de maintenir cet état : ne jamais coller un vrai numéro dans un rapport de bug, ne jamais prendre en capture d’écran un tunnel d’achat en direct, et ne jamais importer un extrait de production pour rendre les données de test réalistes.
Le mode de défaillance organisationnel tient généralement à l’intention plutôt qu’à la négligence. Quelqu’un a besoin de reproduire un défaut de production, importe une tranche de production pour ce faire, et laisse la tranche en place. Une règle selon laquelle les données de test doivent être générées plutôt que copiées est facile à tenir tant qu’elle n’a jamais été assouplie.
Quels cas de formulaire de paiement valent la peine d’être écrits
Les cas qui interceptent de vrais défauts sont ceux qui se situent aux frontières. Testez un numéro d’un chiffre plus court et d’un chiffre plus long que la longueur attendue pour chaque réseau pris en charge, et vérifiez que le formulaire rejette les deux avec un message sur lequel un utilisateur pourrait agir. Testez un préfixe qui appartient à un réseau que votre tunnel d’achat n’accepte pas, et confirmez que le rejet est clair plutôt que générique.
Testez la clé de contrôle explicitement en prenant un numéro valide et en modifiant un chiffre du milieu, puis en vérifiant que le formulaire le rejette. Ce cas est précieux car il distingue les formulaires qui exécutent réellement la somme de contrôle de ceux qui se contentent de compter les chiffres, et le second type est plus courant qu’il ne devrait l’être.
Testez le formatage et le collage. Les utilisateurs collent des numéros avec des espaces, avec des traits d’union, et avec un espace en début ou en fin, et un champ qui stocke ces caractères sans modification échouera en aval. Testez le champ du code de sécurité contre la longueur attendue du réseau, et testez une date d’expiration pour le mois précédent et pour le mois courant, car la frontière entre ces deux-là est là où vivent les erreurs de décalage d’une unité. L’article sur le format du numéro de carte énumère les règles structurelles qui sous-tendent tout cela.
Testez ensuite ce qui se passe après un échec. Un utilisateur qui se trompe sur un chiffre devrait pouvoir le corriger sans ressaisir tout le formulaire, et l’erreur ne devrait pas effacer les autres champs. Ce comportement est rarement vérifié et fréquemment cassé. Le générateur de numéros de carte de ce site est conçu pour produire des numéros sur les réseaux pris en charge, avec la bonne longueur et une clé de contrôle valide, afin qu’une matrice de ces cas puisse être assemblée sans écrire à la main une fixture pour chacun.
Ce qu’un numéro de carte généré est et n’est pas
Un numéro de carte généré est une donnée de test synthétique. Il possède un préfixe bien formé, une longueur correcte pour son réseau et une clé de contrôle valide, et il est conçu pour exercer un logiciel. Ce n’est pas un identifiant de paiement, il n’est émis par aucune banque ni aucun réseau, il n’est rattaché à aucun compte, et il ne peut pas servir à effectuer un achat, à autoriser une transaction ou à franchir une vérification réelle.
Il ne doit pas servir à obtenir des biens ou des services, à tester un système de paiement en production avec l’intention de réaliser une transaction, à usurper l’identité d’un titulaire de carte, ni à franchir un contrôle qui existe pour protéger de vrais comptes. Il existe pour que vos propres formulaires, analyseurs et logiques de validation puissent être testés, et pour rien d’autre.
Lorsqu’un numéro de carte est combiné avec un nom, une adresse et une date de naissance dans un enregistrement, l’enregistrement entier est synthétique. La structure correcte et la cohérence interne sont les propriétés qui le rendent utile ; elles ne sont pas des affirmations sur quoi que ce soit de réel, et aucune partie d’un tel enregistrement ne devrait jamais être présentée comme les données financières de quiconque.