Credit Card Validation in Python — 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 total % 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.

New BIN ranges and co-branded cards

Mastercard expanded its BIN range from 51–55 to include 2221–2720 in 2017. Any hardcoded table from before that date silently rejects newer Mastercard numbers. Co-branded cards (e.g. Visa/Electron, Mastercard/Maestro) add further complexity — the same BIN prefix may be valid on multiple networks.

Virtual cards and tokenised PANs

Virtual card numbers (Apple Pay, Google Pay, bank-issued virtual cards) use valid BIN ranges that differ from their physical counterparts. A DIY BIN table quickly goes stale as issuers roll out new virtual card programs.

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

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.

Client-side Luhn pre-check

Run Luhn validation before hitting the API. This gives instant feedback without a network round-trip — and avoids wasting API calls on obviously invalid numbers.

# Pre-check before calling the API
def luhn_check(number: str) -> bool:
    digits = [int(d) for d in number if d.isdigit()]
    odd_digits = digits[-1::-2]
    even_digits = digits[-2::-2]
    total = sum(odd_digits)
    for d in even_digits:
        total += sum(divmod(d * 2, 10))
    return total % 10 == 0

card_input = input("Card number: ").strip()
if not luhn_check(card_input):
    print("Invalid card number — please check and try again")
else:
    result = validate_card(card_input)
    print(f"{result['network']} — {'valid' if result['valid'] else 'invalid'}")

Test card numbers

These numbers are published by payment processors for testing. They all pass Luhn but do not represent real accounts:

TEST_CARDS = {
    "4111111111111111": "Visa",
    "5500000000000004": "Mastercard",
    "371449635398431":  "Amex",
    "6011111111111117": "Discover",
    "3530111333300000": "JCB",
    "30569309025904":   "Diners Club",
}

for number, network in TEST_CARDS.items():
    result = validate_card(number)
    assert result["valid"], f"{network} test card should be valid"
    assert result["network"] == network, f"Expected {network}, got {result['network']}"

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.

Virtual and co-branded cards

Apple Pay, Google Pay, and bank-issued virtual cards use valid BIN ranges that may differ from their physical counterparts. The API's BIN database is updated regularly, so you don't need to track these changes yourself.