Credit Card Validation in Node.js — Luhn Algorithm Explained

Step 1 — Remove spaces, work right to left

Strip all non-digit characters. Starting from the second-to-last digit and moving left, double every second digit.

Blue = doubled (every 2nd digit from right, starting at position 2)

Step 2 — Subtract 9 from any doubled result > 9

For example, doubling 6 gives 12 → subtract 9 → 3. In this example all doubled digits are 1→2, so no adjustment needed.

Step 3 — Sum all digits

4 + 2 + 1 + 2 + 1 + 2 + 1 + 2 + 1 + 2 + 1 + 2 + 1 + 2 + 1 + 2 = 28... wait, that's the example simplified. Let's use a realistic card:

For 4111111111111111 the sum is 40.

Step 4 — Check divisibility by 10

If sum % 10 === 0 the number is Luhn-valid. For our test card: 40 % 10 = 0 ✓

Length validation per network

Valid card numbers are 13–19 digits, but the exact length depends on the network. Visa uses 13 or 16 digits. Amex always has 15. Mastercard is always 16. JCB can be 16–19. A 14-digit number that passes Luhn cannot be a valid Visa card.

Network detection (IIN/BIN ranges)

To show the right card logo in your UI, route to the correct processor, or apply network-specific fee rules, you need to identify the card network. This requires matching the first 1–8 digits (the Issuer Identification Number) against a list of BIN ranges — which is considerably more complex than a single regex.

Security — card numbers must not be logged

Sending a card number as a GET query parameter is a PCI-DSS violation because the full number appears in server access logs, browser history, and proxy logs. Validation must happen over POST with the number in the body, or client-side before the number ever leaves the browser.

Test card numbers

Payment processors publish official test card numbers that pass Luhn but should never be accepted in production. Your server-side validator should know about them if you're doing pre-processing checks outside of a payment SDK.

// These all pass Luhn — they are test cards, not real ones:
// 4111 1111 1111 1111  — Visa test
// 5500 0000 0000 0004  — Mastercard test
// 3714 4963 5398 431   — Amex test
// 6011 1111 1111 1117  — Discover test

Do client-side validation first

Run Luhn validation in the browser before the form is submitted. This gives instant feedback without a network round-trip — and means a raw card number never hits your server at all if it's obviously wrong.

// Client-side pre-check (browser, no API key needed)
function luhnCheck(num) {
  const digits = num.replace(/\D/g, '');
  let sum = 0, shouldDouble = false;
  for (let i = digits.length - 1; i >= 0; i--) {
    let d = parseInt(digits[i], 10);
    if (shouldDouble && (d = d * 2 - (d > 4 ? 9 : 0)) > 9) d -= 9;
    sum += d; shouldDouble = !shouldDouble;
  }
  return sum % 10 === 0;
}

cardInput.addEventListener('blur', () => {
  if (!luhnCheck(cardInput.value)) {
    showError('Please check your card number');
  }
});

Input formatting — accept any separator

Users enter card numbers in many formats: 4111-1111-1111-1111, 4111 1111 1111 1111, 4111111111111111. The API strips all non-digit characters automatically — pass the raw user input.

Show the card logo before submission

Use the network field to render the correct card logo as the user types — you can detect the network from just the first 4–6 digits. Call the API after the user types enough digits to identify the network.

// Show logo after 4+ digits typed
cardInput.addEventListener('input', async () => {
  const digits = cardInput.value.replace(/\D/g, '');
  if (digits.length >= 4) {
    const result = await validateCard(digits);
    showCardLogo(result.network); // 'Visa', 'Mastercard', etc.
  }
});

Never log or store raw card numbers

PCI-DSS prohibits storing the full PAN (Primary Account Number) unencrypted. Use your payment processor's tokenisation — pass the token, not the number, to your backend. The IsValid API is for format pre-validation only; the actual charge flow must go through a compliant PSP.