Credit card validator (Luhn)

What is the Luhn algorithm?

The Luhn algorithm, also known as modulus 10, is a mathematical formula created by scientist Hans Peter Luhn in 1954 for IBM. It's used to validate identification numbers like credit cards, debit cards, account numbers, and IMEI codes.

This validator does not verify if the card exists or has funds. It simply confirms the number follows the algorithm's mathematical rules, helping detect typing errors before processing a payment. It's the first line of defense in e-commerce forms.

Major card networks (Visa, MasterCard, American Express, Discover) use Luhn as standard. The algorithm catches nearly all single-digit transcription errors and most transpositions of adjacent digits.

How the algorithm works step by step

The Luhn checksum calculation follows these steps:

• 1. Start from the last digit going left (the check digit).
• 2. Double every second digit (starting with the second-to-last). If the result is greater than 9, subtract 9.
• 3. Sum all digits (doubled and unmodified).
• 4. If the sum modulo 10 is 0, the number is valid.

Example with 4111 1111 1111 1111:

• Start right to left: 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 4
• Double alternates: 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 8
• Reduce above 9: 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 8
• Sum: 1+2+1+2+1+2+1+2+1+2+1+2+1+2+1+8 = 30
• 30 % 10 = 0 → Valid

When and why to validate cards

Validating card numbers before sending to payment processors saves time, money, and improves user experience. Most common use cases:

• Checkout forms: Detect typos in real-time as users type.
• Data migration: Clean databases of incorrectly recorded cards.
• Payment integration testing: Use valid test numbers (like 4111 1111 1111 1111) that pass Luhn but don't charge real money.
• Basic fraud prevention: Reject obviously invalid numbers before attempting charges.

Payment gateways like Stripe, PayPal, and Square perform this validation internally, but doing client-side checks reduces unnecessary API calls and provides immediate feedback. It's especially useful in mobile apps and SPAs where latency matters.

Limitations and common mistakes

The Luhn algorithm does not verify:

• If the card actually exists in the banking system.
• If it's active, expired, or blocked.
• If it has sufficient funds.
• If the CVV or expiration date are correct.

Common implementation mistakes:

• Rejecting spaces or hyphens: Users type 4111-1111-1111-1111. You should sanitize input before validating.
• Not identifying the brand: Visa starts with 4, MasterCard with 51-55 or 2221-2720, AmEx with 34 or 37. Knowing the prefix improves UX (showing the correct logo).
• Confusing validity with authenticity: A Luhn-valid number can be invented. Only an actual transaction confirms it's an active card.

For testing, use official test numbers from each network instead of generating random ones.

Test card numbers by network

These are standard, publicly-known test numbers that pass the Luhn algorithm and are accepted in sandbox mode by processors like Stripe. They aren't issued by any bank, don't charge real money, and are meant for testing checkout forms and integrations.

To test a decline, change the last digit (e.g. 4242 4242 4242 4241): you break the Luhn checksum and the number becomes invalid. The test CVV is usually any 3-digit value (4 for Amex) and the expiry any future month/year.