CVV Validation Algorithm: Luhn, BIN, and CVV Format Checks

The short answer

The CVV validation algorithm is a format check, not an authentication check. It does three things at once: it runs the card number through the Luhn checksum, it confirms the number's length and issuer prefix against a table of card network ranges, and it confirms that the security code field has the digit count that network uses. Three digits for Visa, Mastercard, and Discover, four digits for American Express. Nothing in that sequence contacts an issuing bank. A number that passes every check can still belong to a closed account, and a code that passes the length rule can still be wrong. Only an authorization request settles that.

read more

What each check covers

The Luhn step is a mod-10 checksum. It catches single-digit typos and most transpositions of adjacent digits. It says nothing about whether the account exists. The length and prefix step catches numbers that are structurally impossible for the network they claim, such as a 15-digit string starting with 4. The CVV field check catches truncated or padded input before it reaches a payment gateway. All three are input hygiene. None of them is verification.

related article

Prerequisites

• A table of issuer identification number ranges and card lengths per network
• Raw input from the form or feed, unmodified
• A decision on what a failed check should return to the caller

Procedure

1. Strip every character that is not a digit from the card number field, including spaces and hyphens.
2. Reject the input if the remaining string is empty or longer than 19 digits.
3. Compare the leading digits against your issuer range table and record the matched network, or reject if no range matches.
4. Compare the total length against the lengths allowed for that network and reject on any mismatch.
5. Run the Luhn checksum over the digit string and reject if the total does not divide by 10.
6. Strip non-digits from the security code field and confirm it holds exactly 4 digits for American Express or exactly 3 digits for every other network.
7. Return a result object holding the network, a pass or fail flag, and a reason code for each failed step so the caller can log it.

Worked Luhn example

Take 4242424242424242. Working from the rightmost digit, double every second digit, subtract 9 from any result above 9, then sum everything. The eight doubled digits are each 4, giving 8 apiece for 64. The eight untouched digits are each 2, giving 16. The total is 80, which divides by 10, so the checksum passes. That string is a published test number and carries no account behind it. The arithmetic is the same for any card number.

CVV Validation Software: What It Does and How Merchants Use It

Common mistakes

• Running Luhn before the network lookup, which hides an impossible prefix behind a passing checksum
• Treating a 4-digit code as invalid for every network instead of only for American Express
• Trimming leading zeros, which changes the issuer range
• Logging the full card number and code in plaintext after the check

What validation cannot do

A passing format check is not proof of a live account, available funds, or a correct security code. Those facts sit with the issuer and surface only in an authorization response. Storing a security code after an authorization is prohibited under PCI DSS, so any system that keeps codes in a database is out of scope for compliant processing. Using card data without the cardholder's permission is a criminal offense in the US and most other jurisdictions. Write the validator to reject bad input, log reason codes, and hand the rest to a licensed processor.