To test the Luhn algorithm, run the published vector 79927398713 through your function and confirm it returns valid, then change any single digit and confirm it fails. A correct implementation returns true only when the weighted digit sum is divisible by 10, and returns false for every one-digit mutation, every non-numeric character, and every empty input. Run those three cases first, because they expose the parity, doubling, and digit-sum bugs that break most first drafts.
How Does the Luhn Check Work?
Luhn is a mod 10 checksum applied to a digit string. Starting at the rightmost digit and moving left, double every second digit, subtract 9 from any result above 9, then add all the digits together.
- Strip spaces, hyphens, and any separator before the check runs.
- Walk the digits right to left and double the value at odd offsets from the right.
- If a doubled value exceeds 9, subtract 9 from it.
- Sum everything and accept the input when the total modulo 10 equals zero.
Which Luhn Test Vectors Should You Use?
Use fixed vectors before you use random input, so a failure points to a specific code path. These values are stable across every language and library.
- 79927398713 is valid and is the canonical worked example.
- 79927398710, 79927398711, 79927398712, and 79927398714 through 79927398719 are all invalid.
- 4242424242424242 is valid and is the test PAN published by payment processors.
- 4539148803436467 is valid and exercises an even-length string.
- 0 is valid under the raw math, since the sum is zero, so decide whether your parser allows single digits.
- An empty string must be rejected by the caller, not silently passed by the checksum.
What Edge Cases Break Luhn Implementations?
Parity is the biggest trap. Doubling starts from the right, so the doubled positions flip when the length changes from odd to even, and a test suite built on 16-digit numbers alone will miss it. Always include at least one 15-digit and one 16-digit case.
Other cases worth locking down:
- Leading zeros, such as 0000000000000000, where the sum is zero and the result depends on your length policy.
- Separators like spaces and hyphens, which must be removed before digit parsing rather than treated as characters.
- Non-ASCII digits and letters, which should raise an error instead of returning false.
- Very long input, which should be length-checked to keep the loop bounded.
Does Luhn Validate a CVV?
No. Luhn applies to the primary account number, where the final digit is the check digit. A CVV is a 3 or 4 digit value with no checksum, so any three digits pass a format test. Validate a CVV on length and character class only, and leave the real verification to the issuer.
How Do You Write a Luhn Test Suite?
Combine a fixed table of vectors with two property checks that apply to any input. The first property states that changing exactly one digit always flips the result, because Luhn detects every single-digit error. The second states that swapping an adjacent 0 and 9, such as 09 to 90, is not detected, which is a known limitation rather than a bug.
Finish with a differential test. Generate 10,000 random digit strings of length 1 to 19 and compare your output against a trusted library on every one. Any mismatch is a real defect in one of the two implementations.
What Are the Most Common Luhn Bugs?
- Doubling the leftmost digit instead of starting from the right.
- Skipping the subtract 9 step, which shifts the sum on every doubled digit above 4.
- Treating the check digit as a doubled position.
- Accepting an empty string because the loop never runs and the sum stays zero.
- Using floating point arithmetic instead of integers.
- Returning false on malformed input where a thrown error is the correct contract.
A suite that covers the canonical vector, a mutation test, both parities, malformed input, and a differential run against a reference library will catch every defect listed above.