Numéros de carte de test : à quoi sert vraiment l'algorithme de Luhn, et ce qu'il ne peut pas te dire

L'algorithme, déroulé pour que tu puisses le vérifier à la main

Pars du chiffre le plus à droite, qui est le chiffre de contrôle, et laisse-le tranquille. Va vers la gauche et double un chiffre sur deux — celui immédiatement à gauche du chiffre de contrôle, puis un sur deux ensuite. Chaque fois que le doublement dépasse neuf, retranche neuf, ce qui revient à additionner les deux chiffres du résultat doublé. Additionne maintenant tous les chiffres du numéro, doublés ou non. Si le total est divisible par dix, le numéro passe.

Prenons 4242 4242 4242 4242, le numéro de test le plus publié au monde. Seize chiffres : les positions à doubler sont la première, la troisième, la cinquième et ainsi de suite depuis la gauche — les huit 4. Chaque 4 doublé fait 8, ce qui ne dépasse pas neuf, donc rien n'est retranché. Les huit 2 restent intacts. La somme vaut huit fois 8, soit 64, plus huit fois 2, soit 16, donc 80. Quatre-vingts divisé par dix fait huit sans reste : le numéro est valide. Un second exemple à chiffres variés, au cas où la répétition masquerait la méthode : 4539 1488 0343 6467 donne la suite 8, 5, 6, 9, 2, 4, 7, 8, 0, 3, 8, 3, 3, 4, 3, 7, dont le total est également 80.

Produire un numéro valide plutôt que d'en vérifier un, c'est la même arithmétique à l'envers. Prends les chiffres voulus sans le dernier, calcule la somme comme ci-dessus en traitant la position manquante comme le chiffre de contrôle, et le chiffre de contrôle est ce qui porte le total au multiple de dix suivant. Pour 424242424242424, la réponse est 2. Pour 37828224631000, un corps Amex de quatorze chiffres, c'est 5 — d'où le 378282246310005 publié comme numéro de test Amex. Un générateur ne fait rien d'autre.

Ce qu'il attrape, en épuisant les cas

Ce que l'on affirme d'habitude à propos de Luhn, c'est qu'il attrape toutes les erreurs d'un seul chiffre et presque toutes les inversions de chiffres voisins. Les deux moitiés se vérifient par épuisement plutôt qu'elles ne se croient. Change un chiffre de 4242 4242 4242 4242 pour chacune des neuf autres valeurs, à chacune des seize positions : les 144 numéros obtenus échouent tous au contrôle. Cette partie est entière : toute faute de frappe d'un seul chiffre est attrapée, toujours.

La moitié des inversions est presque entière et l'exception est précise. Construis un numéro valide se terminant par chacune des quatre-vingt-dix paires ordonnées de chiffres différents, échange ces deux chiffres, et revérifie : quatre-vingt-huit des quatre-vingt-dix échanges cassent la somme de contrôle. Les deux qui survivent sont 09 devenant 90 et 90 devenant 09. La raison est arithmétique et non mystérieuse : doubler 0 donne 0 et doubler 9 donne 18, qui se réduit à 9 — ces deux chiffres apportent donc la même contribution quelle que soit leur position, et les échanger ne change rien. Il existe un second angle mort, moins cité, dans la même famille : les erreurs jumelles, où une paire doublée est saisie à la place d'une autre paire doublée. Taper 55 pour 22, 66 pour 33 ou 77 pour 44 laisse le total inchangé et passe.

En regard, remarque ce que le contrôle ne tente pas. Il n'a ni secret, ni clé, ni état. N'importe qui calcule un numéro valide en une seconde, et les quatre-vingt-dix pour cent de chaînes de seize chiffres qui échouent au contrôle sont la seule chose qu'il exclut. C'est la bonne conception pour ce à quoi il sert : attraper un client qui a mal tapé un chiffre de sa propre carte, avant que tu ne dépenses un aller-retour réseau et des frais pour l'apprendre. Il n'a jamais eu pour but d'établir qu'une carte existe, et on ne peut pas le lui faire faire.

Le numéro, le compte et l'autorisation sont trois choses différentes

Un numéro de carte a une structure. Les premiers chiffres sont l'identifiant de l'émetteur, qui désigne le réseau et l'établissement et s'attribue selon l'ISO/CEI 7812-1 ; les chiffres suivants sont l'identifiant de compte alloué par l'émetteur ; le dernier est le chiffre de contrôle. Une structure, c'est tout ce que c'est. Savoir qu'un numéro commence par un préfixe d'émetteur valide et se termine par un chiffre de contrôle correct te dit que la chaîne est bien formée, exactement comme un code postal correctement écrit ne dit rien de l'existence d'une maison à cet endroit.

Qu'un compte se trouve derrière le numéro, qu'il soit ouvert, qu'il ait de quoi couvrir le montant, que les règles de risque de l'émetteur autorisent ce commerçant ce jour-là — rien de tout cela n'est dans les chiffres. C'est une demande d'autorisation qui y répond : ton prestataire envoie les données au réseau, le réseau les route vers l'émetteur, et l'émetteur répond par une approbation ou un code de refus. Cet aller-retour est la seule chose qui sait. C'est aussi la seule chose qui peut refuser pour provision insuffisante, pour carte déclarée perdue, ou parce que le cryptogramme ne correspondait pas — soit exactement l'éventail de résultats que ton tunnel de paiement doit traiter correctement.

C'est pourquoi les prestataires publient des numéros de test plutôt que de te dire d'en générer. Stripe documente un numéro précis par marque et un jeu supplémentaire produisant des échecs nommés, de sorte que tu puisses écrire un test affirmant que ta page affiche le bon message quand une carte est refusée pour provision insuffisante plutôt que pour cryptogramme erroné. Adyen publie sa propre liste et dit clairement que ces numéros ne fonctionnent qu'avec sa plateforme de test et ne fonctionnent pas ailleurs. PayPal publie des données de carte pour son bac à sable. Chaque liste est liée à l'environnement de test d'un prestataire, et elle existe parce que la chose utile à tester n'est pas de savoir si une chaîne ressemble à une carte, mais si ton code traite ce qui revient.

Ce que ce générateur produit, confronté aux plages publiées

La mécanique est saine. Vingt mille numéros par marque sur six marques, 120 000 en tout, et tous passent le contrôle de Luhn — pas un seul échec, revérifié après chaque modification des plages. Chaque préfixe produit tombe dans une plage que le réseau publie réellement. Les longueurs suivent la marque : seize chiffres pour Mastercard, Discover et JCB, quinze pour American Express, quatorze pour la plage Diners utilisée, et Visa à seize chiffres neuf fois sur dix, avec treize et dix-neuf une fois sur vingt chacun, parce que Visa émet les trois et qu'un formulaire n'acceptant que seize chiffres contient un bug qu'aucune donnée de test uniforme ne te montrera. Les largeurs de cryptogramme sont justes aussi : trois chiffres partout sauf American Express, où c'est quatre.

Mastercard est la plage qui mérite qu'on la comprenne, à cause de la façon dont elle est tirée plutôt qu'à cause d'un manque. Le réseau a été 51 à 55 pendant des décennies ; depuis 2017 il émet aussi dans la série 2, un intervalle allant de 222100 à 272099 que les commerçants devaient accepter à partir de mi-2017. Une liste plate de préfixes ne peut pas exprimer cela — ce sont cinq cent mille préfixes à six chiffres — donc chaque plage est tenue comme un intervalle numérique inclusif et le préfixe est tiré à l'intérieur. Les deux plages sont tirées à parts égales, moitié-moitié, et c'est une décision de données de test, pas une photographie du marché. Pondérée par les cartes en circulation, la série 2 pèserait quelques pour cent, et au réglage par défaut de cinq cartes un développeur n'en verrait jamais une : c'est précisément le défaut qu'il fallait éviter. Vingt mille Mastercard générées se répartissent 49,7 contre 50,3 entre les deux. Si ton motif de validation a été écrit avant 2017, ou à partir de la sortie d'un générateur plutôt que des plages publiées par le réseau, il rejette une vraie carte de la série 2 et tu l'apprends par un client.

Un préfixe personnalisé n'écrase plus la marque, parce que la marque n'est plus prise dans le sélecteur du tout : elle est lue sur les chiffres. Tape 51 et tu obtiens une Mastercard, quoi que dise le sélecteur de type. Tape un simple 9, un premier chiffre que l'ISO/CEI 7812-1 réserve à l'attribution nationale et qu'aucun réseau ne possède, et la carte revient étiquetée BIN inconnu sur une face grise neutre, plutôt que déguisée en Visa. Un préfixe court ne revendique une plage que si tous les numéros qu'il pourrait produire tombent dedans : 51 est une Mastercard, un 5 tout seul non, parce que 50 et 56 à 59 n'en sont pas — un BIN à moitié tapé se lit donc comme inconnu, ce qui est la réponse honnête pendant que le champ se remplit. La marque lue sur les chiffres commande ensuite le reste de la carte : la longueur et la largeur du cryptogramme suivent le préfixe et non le menu, si bien qu'un BIN Amex tapé donne quinze chiffres et un cryptogramme à quatre. Le menu de préfixes prêts à l'emploi n'a jamais eu ce problème : en choisir un fixe la marque en conséquence.

Un dernier point sur le menu de préfixes, la partie la plus utile de l'outil et aussi la plus facile à mal lire. Les onze préfixes proposés — 4242, 4000, 5555, 5200, 3782, 6011, 3566, 3622, 4111, 5100 et 4032 — sont les premiers chiffres des numéros que les prestataires publient comme données de test, pas ceux de vraies banques, et la page le dit. Mais un numéro généré commençant par 4242 n'est pas la carte de test de Stripe. La carte de test de Stripe, c'est exactement 4242 4242 4242 4242, une chaîne précise ; le générateur produit un autre numéro, aléatoire, valide selon Luhn, avec les mêmes quatre premiers chiffres, et l'environnement de test d'un prestataire reconnaît le numéro documenté et non le préfixe. Un préfixe choisi fixe aussi la longueur à celle qui est canonique pour la marque : un 4242 revient toujours en seize chiffres, jamais dans les formes plus rares de Visa à treize ou dix-neuf. Sers-toi du menu pour rendre tes jeux de test plausibles. Sers-toi de la documentation du prestataire pour les rendre fonctionnels.

Questions fréquentes

Un numéro qui passe le contrôle de Luhn signifie-t-il que la carte est réelle ?

Non, pas même un peu. Luhn est une somme de contrôle sans clé ni secret : n'importe qui calcule un numéro valide en moins d'une seconde, et environ une chaîne de seize chiffres sur dix passe par hasard. Ce qu'il exclut, ce sont les neuf sur dix qui ne passent pas — un filtre à fautes de frappe, rien d'autre. Savoir si un compte existe derrière le numéro, s'il est ouvert et s'il autoriserait un montant donné relève de l'émetteur seul, par une demande d'autorisation acheminée par ton prestataire de paiement. C'est pourquoi le contrôle se fait dans le navigateur avant l'envoi de la demande, et non à sa place.

Puis-je utiliser un numéro généré pour tester mon intégration de paiement ?

Pour la moitié côté client, oui : un numéro bien formé, de la bonne longueur et au chiffre de contrôle valide, est exactement ce qu'il faut pour voir si ton formulaire l'accepte, le met en groupes de quatre, affiche le bon logo de marque et demande trois chiffres plutôt que quatre. Pour tout ce qui vient après, non. L'environnement de test d'un prestataire reconnaît les numéros précis qu'il publie, et un numéro aléatoire partageant les quatre premiers chiffres avec l'un d'eux n'en est pas un. Stripe, Adyen et PayPal documentent chacun une liste, et la partie utile de ces listes, ce sont les numéros qui échouent exprès — un pour provision insuffisante, un pour carte perdue, un pour cryptogramme non concordant — car traiter correctement un refus est la partie d'un tunnel de paiement qui casse vraiment.

Quelles inversions Luhn laisse-t-il passer ?

Exactement une paire voisine : 09 tapé 90, et 90 tapé 09. Teste les quatre-vingt-dix paires ordonnées de chiffres différents et quatre-vingt-huit des échanges sont attrapés. L'exception découle de l'arithmétique : doubler 0 donne 0 et doubler 9 donne 18, qui se réduit à 9 — la paire apporte donc 9 dans les deux sens. Il existe un second angle mort, moins souvent cité, d'une autre famille : les erreurs jumelles, où une paire doublée est saisie à la place d'une autre paire doublée. Saisir 55 au lieu de 22, 66 au lieu de 33 ou 77 au lieu de 44 laisse la somme inchangée et passe. Ce sont deux limites connues d'un procédé conçu dans les années 1950 pour attraper un chiffre recopié à la main, et toutes deux sont sans rapport avec la sécurité, puisque Luhn n'a jamais été un contrôle de sécurité.

Pourquoi ma validation rejette-t-elle une vraie Mastercard commençant par 2 ?

Parce que la règle a été écrite d'après l'ancienne plage. Mastercard a été 51 à 55 pendant des décennies, et bien des motifs de validation le disent encore. Le réseau a ajouté la série 2 en 2017, une plage allant de 222100 à 272099, et les commerçants devaient l'accepter. Un motif antérieur hérite du trou, et un motif dérivé d'un générateur qui n'émettait que 51 à 55 aussi — c'est ce que faisait celui-ci. Il tire désormais les deux plages à parts égales, sa sortie couvre donc les deux ; mais écris le motif d'après les plages publiées par le réseau plutôt que d'après un générateur, et traite la détection de marque par préfixe comme un entretien et non comme un travail unique, parce que les plages changent.

Est-il légal de générer des numéros de carte ?

Calculer un chiffre de contrôle est de l'arithmétique, et l'arithmétique seule n'est pas la question. Ce qui compte est l'usage fait du numéro. Construire un jeu d'essai pour exercer un formulaire est un travail logiciel ordinaire ; tenter d'obtenir un bien ou un service avec un numéro que personne ne t'a délivré est une fraude, partout, indépendamment du fait qu'il satisfasse une somme de contrôle. Il n'existe pas de zone grise utile ici, car un numéro généré ne peut de toute façon rien acheter : aucun compte ne se trouve derrière et aucun émetteur ne l'autorisera. Le conseil pratique rejoint donc le conseil technique : prends les numéros de test publiés par ton prestataire, garde-les dans ta suite de tests, et ne mets jamais un vrai numéro de carte dans un environnement de développement — sujet sur lequel ton contrat avec ce prestataire et la norme de sécurité des données du secteur ont l'un comme l'autre beaucoup à dire.