REGEXVAULTv2.0
Finance/Card Numbers
Verified Safe

Generic Payment Card Number (13–19 digits) Regex for Java

/^(?:[0-9]{4}([\s-])[0-9]{4}\1[0-9]{4}\1[0-9]{1,7}|[0-9]{13,19})$/

What this pattern does

This page provides a well-structured, multi-part regular expression for matching generic payment card number (13–19 digits), ported and verified for Java. Financial data validation has zero tolerance for false negatives — a missed invalid entry can corrupt downstream calculations. The snippet below is ready to drop into your Java project — whether you're validating in a Spring Boot controller, a Jakarta EE service, or a standalone utility class.

Java Implementation

Java
// Generic Payment Card Number (13–19 digits)
// ReDoS-safe | RegexVault — Finance > Card Numbers

import java.util.regex.Pattern;

public class GenericPaymentCardNumber1319DigitsValidator {
    private static final Pattern PATTERN =
        Pattern.compile("^(?:[0-9]{4}([\\s-])[0-9]{4}\\1[0-9]{4}\\1[0-9]{1,7}|[0-9]{13,19})$");

    public static boolean validate(String input) {
        return PATTERN.matcher(input).matches();
    }

    // Example
    public static void main(String[] args) {
        System.out.println(validate("4111111111111111")); // true
    }
}

Test Cases

Matches (Valid)
Rejects (Invalid)
411111111111111141111111111111111111
4111 1111 1111 11114111-1111 1111-1111
4111-1111-1111-1111abcd1234abcd1234
5500005555555559
378282246310005
411111111111111

When to use this pattern

This pattern is drawn from the Finance > Card Numbers category and carries a ReDoS-safe certification. That matters for Java developers because critical in Java applications since the JVM regex engine uses backtracking and is susceptible to ReDoS without careful pattern design. RegexVault audits patterns against known backtracking attack vectors, ensuring you have the necessary context before using this regex in a high-stakes production environment.

Common Pitfalls

Never log full card numbers. Mask to show only the last 4 digits (XXXX XXXX XXXX 1234). PCI-DSS compliance requires minimizing the surface area that touches full PANs.

Technical Notes

Format only — does not validate the Luhn checksum. Always implement Luhn algorithm validation separately. PCI-DSS prohibits storing full PANs (Primary Account Numbers) without encryption.

Have a pattern that belongs in the vault?

Submit it for review — community-verified patterns get credited to your GitHub handle. Free submissions join the queue. Priority review available for $15.

Submit a Pattern