Vérifier une carte bancaire avec l’algorithme de Luhn
Ce validateur supprime les espaces et les traits d’union usuels du numéro fourni, exige que tous les caractères restants soient des chiffres, puis applique la somme de contrôle déterministe de Luhn.
Lancer gratuitement
Il indique aussi le réseau probable d’après les préfixes reconnus de Visa, Mastercard, American Express et Discover. Le résultat repère des erreurs de saisie avant une demande de paiement, mais ne prouve ni l’existence ni l’activité du compte, son titulaire ou la possibilité de régler un achat.
Normalisation et contrôle de la saisie
Saisissez le numéro de carte sous forme de chaîne, soit uniquement avec des chiffres, soit dans une présentation courante où les groupes sont séparés par des espaces ou des traits d’union. Le validateur retire seulement ces deux séparateurs. Il exige ensuite que chaque caractère restant soit un chiffre ASCII. Les lettres, signes de ponctuation, barres obliques, tirets bas et autres symboles déclenchent une erreur de saisie au lieu d’être supprimés discrètement. Cette rigueur évite qu’un nettoyage trop large transforme une valeur accidentelle ou mal formée en un autre numéro et fournisse une réponse trompeuse. Une chaîne vide, une valeur composée uniquement de séparateurs ou une valeur d’un autre type est également refusée. L’objet renvoyé ne reproduit jamais le numéro normalisé : il contient seulement le verdict de la somme de contrôle et le réseau probable. Dans votre application, considérez toujours l’entrée originale comme une donnée de paiement sensible, même si ce calcul local n’utilise ni consultation d’émetteur, ni autorisation, ni réseau, ni hasard, ni stockage persistant.
Interpréter correctement le résultat de Luhn
L’algorithme de Luhn calcule un chiffre de contrôle destiné à repérer les erreurs de transcription fréquentes. En partant du chiffre le plus à droite, le validateur conserve alternativement un chiffre et double le suivant. Si un résultat doublé dépasse neuf, il lui retranche neuf, additionne toutes les valeurs obtenues, puis accepte le numéro lorsque le total est divisible par dix. Un résultat positif signifie uniquement que la suite est mathématiquement cohérente avec son dernier chiffre de contrôle. Il ne démontre pas qu’une banque a émis ce numéro, que le compte est ouvert, qu’il dispose de fonds ou que la personne peut l’utiliser. Une suite inventée peut réussir ce test, tandis qu’une vraie carte comportant un chiffre erroné échoue généralement. Servez-vous-en comme retour immédiat dans un formulaire ou comme contrôle de qualité, puis confiez la tokenisation, l’authentification, l’autorisation, la lutte contre la fraude et la décision finale à un prestataire de paiement conforme.
Déterminer le réseau probable
Le réseau est déduit du préfixe d’identification de l’émetteur, sans interrogation d’un registre distant. Un numéro commençant par 4 est classé Visa. Mastercard couvre la plage historique de 51 à 55 ainsi que la plage récente de 2221 à 2720. American Express emploie 34 et 37. Discover couvre 6011, 65, la plage de 644 à 649 et celle de 622126 à 622925. Lorsqu’aucune règle ne correspond, le réseau reste inconnu, mais le verdict de Luhn est calculé normalement. Le terme probable est essentiel : les attributions évoluent, les cartes cobrandées existent et cet outil reconnaît volontairement uniquement les quatre réseaux demandés. La reconnaissance du préfixe et le contrôle arithmétique sont indépendants. Un numéro peut donc présenter un préfixe connu tout en échouant à Luhn, ou réussir Luhn avec un préfixe inconnu. Chaque requête est facturée au tarif de base publié de $0.002, sans supplément lié à la longueur du numéro ou au réseau détecté.
Cas d’usage
Retour pendant la saisie
Repérez un chiffre probablement mal saisi avant de transmettre les données à un prestataire conforme pour autorisation.
Contrôle de données importées
Vérifiez la structure de numéros issus d’archives sans prétendre que les comptes correspondants sont toujours actifs.
Test de formulaire de paiement
Assurez-vous que les séparateurs autorisés sont acceptés et que les caractères incorrects sont refusés uniformément.
Questions fréquentes
La réussite du test de Luhn prouve-t-elle que la carte existe ?
Non. Elle montre seulement que les chiffres respectent une somme de contrôle. L’existence, le titulaire, l’état, les fonds et l’autorisation nécessitent une réponse du prestataire et de l’émetteur.
Quels caractères de mise en forme puis-je utiliser ?
Vous pouvez insérer des espaces et des traits d’union. Ils sont retirés avant le contrôle ; tout autre caractère non numérique provoque une erreur de saisie.
Quels réseaux de cartes sont reconnus ?
Les règles de préfixe identifient probablement Visa, Mastercard, American Express et Discover. Tout autre préfixe donne un réseau inconnu.
Un préfixe reconnu peut-il échouer au contrôle ?
Oui. Le classement du préfixe et le calcul de Luhn sont indépendants ; un préfixe de type Visa ne garantit donc pas une somme correcte.
Le validateur contacte-t-il une banque ou un réseau ?
Non. La réponse repose sur un calcul déterministe et des règles de préfixe, sans consultation distante ni tentative d’autorisation.
Pour les développeurs — accès API
Tout sur cette page est disponible par programmation. Cette section s'adresse aux équipes qui veulent l'intégrer à leurs systèmes ; les autres peuvent simplement utiliser l'outil ci-dessus.
Endpoint
Authentification par jeton Bearer : un seul POST met la tâche en file d’attente, et le résultat vous parvient par webhook ou lien signé.
Appeler depuis votre stack
curl -X POST https://api.kit.forhosting.com/data/credit-card-luhn-validate \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"number":"4111 1111 1111 1111"}'const res = await fetch("https://api.kit.forhosting.com/data/credit-card-luhn-validate", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"number": "4111 1111 1111 1111"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/data/credit-card-luhn-validate",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"number": "4111 1111 1111 1111"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/data/credit-card-luhn-validate", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"number":"4111 1111 1111 1111"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"number":"4111 1111 1111 1111"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/data/credit-card-luhn-validate", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Exemple de requête
{
"number": "4111 1111 1111 1111"
}Exemple de réponse
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "data.credit_card_luhn_validate",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}L’API est asynchrone : chaque appel renvoie un task_id immédiatement, puis vous interrogez l’état à raison d’une requête par seconde.
Tarifs
Le prix est publié, sans tokens ni crédits. Une tâche qui échoue n’est pas facturée.
Limites
max_mb | 25 |
Erreurs
| HTTP | Code | Signification |
|---|---|---|
401 | unauthorized | Clé API absente ou invalide : vérifiez l’en-tête Authorization. |
402 | insufficient_balance | Solde insuffisant : rechargez votre compte pour lancer cette tâche. |
404 | unknown_type | Type de tâche inconnu : vérifiez le champ type de votre requête. |
429 | rate_limited | Trop de requêtes : ralentissez la cadence, puis réessayez. |