You’re given the job of implementing an order form for a company that accepts payment by credit card. Since the credit card processor charges for each transaction attempt, including failed attempts, you want to use a regular expression to weed out obviously invalid credit card numbers.
Doing this will also improve the customer’s experience. A regular expression can instantly detect obvious typos as soon as the customer finishes filling in the field on the web form. A round trip to the credit card processor, by contrast, easily takes 10 to 30 seconds.
To keep the implementation simple, this solution is split into two parts. First we strip out spaces and hyphens. Then we validate what remains.
Retrieve the credit card number entered by the customer and store it into a variable. Before performing the check for a valid number, perform a search-and-replace to strip out spaces and hyphens. Replace all matches of this regular expression with blank replacement text:
[●-]| Regex options: None |
| Regex flavors: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby |
Recipe 3.14 shows you how to perform this initial replacement.
With spaces and hyphens stripped from the input, the next regular expression checks if the credit card number uses the format of any of the six major credit card companies. It uses named capture to detect which brand of credit card the customer has:
^(?:
(?<visa>4[0-9]{12}(?:[0-9]{3})?) |
(?<mastercard>5[1-5][0-9]{14}) |
(?<discover>6(?:011|5[0-9]{2})[0-9]{12}) |
(?<amex>3[47][0-9]{13}) |
(?<diners>3(?:0[0-5]|[68][0-9])[0-9]{11}) |
(?<jcb>(?:2131|1800|35[0-9]{3})[0-9]{11})
)$| Regex options: Free-spacing |
| Regex flavors: .NET, Java 7, XRegExp, PCRE 7, Perl 5.10, Ruby 1.9 |
^(?:
(?P<visa>4[0-9]{12}(?:[0-9]{3})?) |
(?P<mastercard>5[1-5][0-9]{14}) |
(?P<discover>6(?:011|5[0-9]{2})[0-9]{12}) |
(?P<amex>3[47][0-9]{13}) |
(?P<diners>3(?:0[0-5]|[68][0-9])[0-9]{11}) |
(?P<jcb>(?:2131|1800|35[0-9]{3})[0-9]{11})
)$| Regex options: Free-spacing |
| Regex flavors: PCRE, Python |
Java 4 to 6, Perl 5.8 and earlier, and Ruby 1.8 do not support named capture. You can use numbered capture instead. Group 1 will capture Visa cards, group 2 MasterCard, and so on up to group 6 for JCB:
^(?:
(4[0-9]{12}(?:[0-9]{3})?) | # Visa
(5[1-5][0-9]{14}) | # MasterCard
(6(?:011|5[0-9]{2})[0-9]{12}) | # Discover
(3[47][0-9]{13}) | # AMEX
(3(?:0[0-5]|[68][0-9])[0-9]{11}) | # Diners Club
((?:2131|1800|35[0-9]{3})[0-9]{11}) # JCB
)$| Regex options: Free-spacing |
| Regex flavors: .NET, Java, XRegExp, PCRE, Perl, Python, Ruby |
Standard JavaScript does not support named capture or free-spacing. Removing whitespace and comments, we get:
^(?:(4[0-9]{12}(?:[0-9]{3})?)|(5[1-5][0-9]{14})|↵
(6(?:011|5[0-9]{2})[0-9]{12})|(3[47][0-9]{13})|↵
(3(?:0[0-5]|[68][0-9])[0-9]{11})|((?:2131|1800|35[0-9]{3})[0-9]{11}))$| Regex options: None |
| Regex flavors: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby |
If you don’t need to determine which type the card is, you can remove the six capturing groups that surround the pattern for each card type, as they don’t serve any other purpose.
Follow Recipe 3.6 to add this regular expression to your order form to validate the card number. If you use different processors for different cards, or if you just want to keep some statistics, you can use Recipe 3.9 to check which named or numbered capturing group holds the match. That will tell you which brand of credit card the customer has.
<html>
<head>
<title>Credit Card Test</title>
</head>
<body>
<h1>Credit Card Test</h1>
<form>
<p>Please enter your credit card number:</p>
<p><input type="text" size="20" name="cardnumber"
onkeyup="validatecardnumber(this.value)"></p>
<p id="notice">(no card number entered)</p>
</form>
<script>
function validatecardnumber(cardnumber) {
// Strip spaces and dashes
cardnumber = cardnumber.replace(/[ -]/g, '');
// See if the card is valid
// The regex will capture the number in one of the capturing groups
var match = /^(?:(4[0-9]{12}(?:[0-9]{3})?)|(5[1-5][0-9]{14})|↵
(6(?:011|5[0-9]{2})[0-9]{12})|(3[47][0-9]{13})|(3(?:0[0-5]|[68][0-9])↵
[0-9]{11})|((?:2131|1800|35[0-9]{3})[0-9]{11}))$/.exec(cardnumber);
if (match) {
// List of card types, in the same order as the regex capturing groups
var types = ['Visa', 'MasterCard', 'Discover', 'American Express',
'Diners Club', 'JCB'];
// Find the capturing group that matched
// Skip the zeroth element of the match array (the overall match)
for (var i = 1; i < match.length; i++) {
if (match[i]) {
// Display the card type for that group
document.getElementById('notice').innerHTML = types[i - 1];
break;
}
}
} else {
document.getElementById('notice').innerHTML = '(invalid card number)';
}
}
</script>
</body>
</html>On an actual credit card, the digits of the embossed card number are usually placed into groups of four. That makes the card number easier for humans to read. Naturally, many people will try to enter the card number in the same way, including the spaces, on order forms.
Writing a regular expression that validates a card number, allowing for spaces, hyphens, and whatnot, is much more difficult that writing a regular expression that only allows digits. Thus, unless you want to annoy the customer with retyping the card number without spaces or hyphens, do a quick search-and-replace to strip them out before validating the card number and sending it to the card processor.
The regular expression ‹[●-]› matches a character that is a space
or a hyphen. Replacing all matches of this regular expression with
nothing effectively deletes all spaces and hyphens.
Each of the credit card companies uses a different number format. We’ll exploit that difference to allow users to enter a number without specifying a company; the company can be determined from the number. The format for each company is:
- Visa
13 or 16 digits, starting with
4.- MasterCard
16 digits, starting with
51through55.- Discover
16 digits, starting with
6011or65.- American Express
15 digits, starting with
34or37.- Diners Club
14 digits, starting with
300through305,36, or38.- JCB
15 digits, starting with
2131or1800, or 16 digits starting with35.
If you accept only certain brands of credit cards, you can
delete the cards that you don’t accept from the regular expression.
When deleting JCB, make sure to delete the last remaining ‹|› in the regular expression as
well. If you end up with ‹||› or ‹|)› in your regular expression, it will accept
the empty string as a valid card number.
For example, to accept only Visa, MasterCard, and AMEX, you can use:
^(?:
4[0-9]{12}(?:[0-9]{3})? | # Visa
5[1-5][0-9]{14} | # MasterCard
3[47][0-9]{13} # AMEX
)$| Regex options: Free-spacing |
| Regex flavors: .NET, Java, XRegExp, PCRE, Perl, Python, Ruby |
Alternatively:
^(?:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|3[47][0-9]{13})$| Regex options: None |
| Regex flavors: .NET, Java, JavaScript, PCRE, Perl, Python, Ruby |
If you’re searching for credit card numbers in a larger body of
text, replace the anchors with ‹\b› word
boundaries.
The section Example web page with JavaScript
shows how you could add these two regular expressions to your order
form. The input box for the credit card number has an onkeyup event handler that calls
the validatecardnumber() function. This function retrieves the card number from
the input box, strips the spaces and hyphens, and then validates it
using the regular expression with numbered capturing groups. The
result of the validation is displayed by replacing the text in the
last paragraph on the page.
If the regular expression fails to match, regexp.exec()null, and
(invalid card number) is displayed. If the
regex does match, regexp.exec()
Our regular expression has six capturing groups, divided by
alternation. This means that exactly one capturing group will
participate in the match and hold the card number. The other groups
will be empty (either undefined or the empty string, depending on your
browser). The function checks the six capturing groups, one by one.
When it finds one that is not empty, the card number is recognized and
displayed.
There is an extra validation check that you can do on the credit card number before processing the order. The last digit in the credit card number is a checksum calculated according to the Luhn algorithm. Since this algorithm requires basic arithmetic, you cannot implement it with a regular expression.
You can add the Luhn check to the web page example for this recipe
by inserting the call luhn(cardnumber); before the “else” line in the
validatecardnumber()
function. This way, the Luhn check will be done only if the regular
expression finds a valid match, and after determining the card brand.
However, determining the brand of the credit card is not necessary for
the Luhn check. All credit cards use the same method.
In JavaScript, you can code the Luhn function as follows:
function luhn(cardnumber) {
// Build an array with the digits in the card number
var digits = cardnumber.split('');
for (var i = 0; i < digits.length; i++) {
digits[i] = parseInt(digits[i], 10);
}
// Run the Luhn algorithm on the array
var sum = 0;
var alt = false;
for (i = digits.length - 1; i >= 0; i--) {
if (alt) {
digits[i] *= 2;
if (digits[i] > 9) {
digits[i] -= 9;
}
}
sum += digits[i];
alt = !alt;
}
// Check the result
if (sum % 10 == 0) {
document.getElementById('notice').innerHTML += '; Luhn check passed';
} else {
document.getElementById('notice').innerHTML += '; Luhn check failed';
}
}This function takes a string with the credit card number as a
parameter. The card number should consist only of digits. In our
example, validatecardnumber() has already stripped spaces
and hyphens and determined the card number to have the right number of
digits.
First, we split the string into an array of individual characters.
Then we iterate over the array to convert the characters into integers.
If we don’t convert them, the sum variable will end up as a string concatenation
of the digits, rather than the integer addition of the numbers.
The actual algorithm runs on the array, calculating a checksum. If the sum modulus 10 is zero, then the card number is valid. If not, the number is invalid.
Techniques used in the regular expressions in this recipe are discussed in Chapter 2. Recipe 2.3 explains character classes. Recipe 2.5 explains anchors. Recipe 2.8 explains alternation. Recipe 2.9 explains grouping. Recipe 2.11 explains named capturing groups. Recipe 2.12 explains repetition.
Get Regular Expressions Cookbook, 2nd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
