NewIntroducing QODEX QA Services — platform-powered QA for API-driven teams.Learn more →
Validateur regex Java de cartes de crédit

Validateur regex Java de cartes de crédit

Le Validateur regex Java de cartes de crédit vous permet de vérifier instantanément si un numéro de carte de crédit correspond aux patterns courants pour Visa, MasterCard, AMEX et d'autres types, en utilisant regex Java. Cela est essentiel dans les systèmes de paiement, les formulaires d'inscription et les applications e-commerce.

Essayez d'autres outils Java pour la validation des entrées :


Validateur regex Java de cartes de crédit - Documentation

Qu'est-ce qu'un regex de carte de crédit ?

Les numéros de cartes de crédit suivent des normes de formatage strictes définies par les réseaux de cartes. Un regex de carte de crédit permet de s'assurer que la structure du numéro correspond au format attendu avant une vérification plus approfondie comme l'algorithme de Luhn.

Chaque type de carte possède un ou plusieurs chiffres de départ spécifiques et une longueur définie :

Type de carte

Commence par

Longueur

Visa

4

13 ou 16

MasterCard

51 à 55 ou 2221 à 2720

16

AMEX

34 ou 37

15

Ces patterns permettent d'identifier l'émetteur simplement en regardant le numéro :

  • Visa : 13 ou 16 chiffres, commençant toujours par 4.

  • MasterCard : 16 chiffres, commençant par 51 à 55 ou 2221 à 2720.

  • Discover : 16 chiffres, commençant par 6011 ou 65.

  • American Express : 15 chiffres, commence par 34 ou 37.

  • Diners Club : 14 chiffres, commence par 300 à 305, 36 ou 38.

  • JCB : 15 chiffres commençant par 2131 ou 1800, ou 16 chiffres commençant par 35.

Patterns regex Java pour les cartes de crédit

Voici quelques patterns regex courants :


Visa :

^4[0-9]{12}(?:[0-9]{3})?$


Mastercard :

^5[1-5][0-9]{14}|^2(2[2-9][0-9]{2}|[3-6][0-9]{3}|7([01][0-9]{2}|20))[0-9]{12}$


American Express :

^3[47][0-9]{13}$

Ces patterns vérifient uniquement la structure, pas la validité réelle de la carte.

Valider plusieurs types de cartes en Java


Si vous validez plusieurs numéros de cartes à la fois, vous pouvez utiliser un pattern regex combiné et les classes Pattern et Matcher de Java. Cette approche est particulièrement utile pour traiter des listes de numéros de cartes provenant de formulaires, d'API ou de validations par lots.

Pensez à toujours assainir les entrées en supprimant les espaces ou les tirets avant d'appliquer le regex. Ainsi, un numéro comme 4111-1111-1111-1111 ne sera pas rejeté à tort à cause du formatage.

Exemple de code Java

import java.util.regex.Pattern;
import java.util.regex.Matcher;

public class CreditCardValidator { public static void main(String[] args) { String visaCard = "4111111111111111"; String visaPattern = "^4[0-9]{12}(?:[0-9]{3})?$";

    Pattern pattern = Pattern.compile(visaPattern);
    Matcher matcher = pattern.matcher(visaCard);

    if (matcher.matches()) {
        System.out.println("Valid Visa card number");
    } else {
        System.out.println("Invalid Visa card number");
    }
}

}

Algorithme de Luhn : vérification des numéros de cartes en Java

Regex garantit qu'un numéro de carte est bien formaté, mais pas qu'il est réellement valide. C'est là qu'intervient l'algorithme de Luhn, une méthode de somme de contrôle intégrée utilisée par les réseaux de cartes pour détecter les fautes de frappe accidentelles et la plupart des faux numéros.

Voici comment il fonctionne :

  1. En partant du chiffre le plus à droite, déplacez-vous vers la gauche en doublant chaque deuxième chiffre.

  2. Si le doublement produit un nombre supérieur à 9, soustrayez 9.

  3. Additionnez tous les chiffres.

  4. Si le total modulo 10 est égal à zéro, le numéro est valide.

Voici une méthode Java simple pour la validation Luhn :

public class LuhnValidator {
public static boolean isValid(String ccNumber) {
int sum = 0;
boolean alternate = false;
for (int i = ccNumber.length() - 1; i >= 0; i--) {
int n = Character.getNumericValue(ccNumber.charAt(i));
if (alternate) {
n *= 2;
if (n > 9) {
n -= 9;
}
}
sum += n;
alternate = !alternate;
}
return (sum % 10 == 0);
}
}

Appelez LuhnValidator.isValid("4111111111111111"). Renvoie true si le numéro passe la vérification Luhn, false sinon.

Cette étape est indispensable pour distinguer un numéro correctement formaté d'un numéro potentiellement valide, avant tout traitement de paiement ou stockage.

Exemples de saisies

Valides :

  • Visa : 4111111111111111

  • MasterCard : 5555555555554444

  • AMEX : 371449635398431

Invalides :

  • 1234567890123456 (préfixe invalide)

  • 411111111111111 (longueur incorrecte)

  • abcdefg12345678 (caractères non numériques)

Cas d'utilisation

  • Formulaires de paiement : validez le format du numéro de carte avant les appels API.

  • Onboarding utilisateur : vérifiez que le format de la carte est correct lors de la configuration.

  • Prévention de la fraude : rejetez rapidement les faux numéros de cartes évidents.

  • Nettoyage de données : validez et nettoyez les numéros de cartes stockés dans des journaux ou des bases de données.

Autres cas d'utilisation courants de regex en Java

Les expressions régulières ne servent pas qu'aux cartes de crédit : elles sont l'outil polyvalent par excellence pour la validation des entrées. Voici quelques cas courants où regex est précieux dans les applications Java :

  • Adresses e-mail : vérifiez que les utilisateurs fournissent des adresses correctement formatées (ex. user@example.com), en détectant les fautes de frappe évidentes.

  • Codes postaux : validez les formats pour différents pays comme les États-Unis (12345 ou 12345-6789), le Canada (K1A 0B1) ou le Royaume-Uni (SW1A 1AA).

  • Numéros de téléphone : vérifiez les patterns valides en Amérique du Nord ((555) 555-1234) et les formats internationaux avec indicatifs pays.

  • Mots de passe : appliquez des règles de complexité : longueur minimale, mélange de majuscules/minuscules, chiffres et symboles spéciaux.

  • Dates : confirmez que les dates sont saisies dans des formats acceptés, comme YYYY-MM-DD ou MM/DD/YYYY.

  • SSN et identifiants fiscaux : identifiez rapidement les numéros de sécurité sociale américains valides (123-45-6789) ou d'autres identifiants fiscaux régionaux.

Conseils avancés

  • Ne jamais stocker les numéros de carte bruts. Utilisez un service de tokenisation sécurisé.

  • Combinez toujours les vérifications regex avec l'algorithme de Luhn pour une validation réelle des numéros de carte.

  • Ne vous fiez pas uniquement à regex pour la détection de fraude : il sert à la validation du format, pas à la légitimité.

  • Assainissez les entrées en supprimant les espaces ou les tirets avant la correspondance regex.

  • Personnalisez le regex si vous ne prenez en charge que certains types de cartes (ex. Visa + MasterCard).

  • Utilisez un pattern séparé par type de carte pour une meilleure expérience utilisateur et des messages de validation ciblés.

Combinez avec ces outils

Frequently Asked Questions

Ce validateur vérifie-t-il si la carte est réelle ?

Non, regex vérifie uniquement la structure. Utilisez l'algorithme de Luhn pour vérifier la légitimité. Pour s'assurer qu'un numéro de carte est non seulement bien formaté mais aussi potentiellement valide, une étape supplémentaire est nécessaire : l'algorithme de Luhn. Cette formule de somme de contrôle utilise une arithmétique simple pour calculer le dernier chiffre du numéro de carte. Contrairement à regex, qui se contente d'appliquer le bon pattern, l'algorithme de Luhn permet d'éliminer la plupart des fautes de frappe et des numéros invalides.

Peut-on utiliser un seul pattern pour tous les types de cartes ?

Vous pouvez les combiner, mais il est préférable de garder des patterns séparés par type de carte pour plus de clarté.

Y a-t-il une différence entre les cartes Visa à 13 et à 16 chiffres ?

Oui. Les deux sont valides selon l'émetteur, incluez donc des chiffres optionnels dans votre regex.

Puis-je valider des entrées formatées comme 4111-1111-1111-1111 ?

Oui, mais vous devez modifier le regex ou assainir l'entrée au préalable.

Dois-je vérifier aussi la date d'expiration et le CVV ?

Oui, mais ceux-ci nécessitent des regex séparés ou des champs de formulaire distincts, qui ne font pas partie de ce pattern.

Testez vos API dès aujourd'hui !

Rédigez en langage naturel, Qodex génère des tests sécurisés et prêts à l'emploi.