That’s a checksum algorithm. You could easily devise something similar for a word based on the characters in it. That doesn’t make it a number.

GP is right. You never do math with two credit card numbers as inputs. You can’t negate a credit card number, or find its absolute value, or square, etc.

It’s just a string of digits.

To reiterate your statement: it's a string with constraints on the glyphs!

Did you even read the wikipedia page I linked?

    If the number already contains the check digit, drop that digit to form the "payload." The check digit is most often the last digit.
    With the payload, start from the rightmost digit. Moving left, double the value of every second digit (including the rightmost digit).
    Sum the digits of the resulting value in each position (using the original value where a digit did not get doubled in the previous step).
    The check digit is calculated by 10 − ( s mod ⁡ 10 ) {\displaystyle 10-(s\operatorname {mod} 10)} {\displaystyle 10-(s\operatorname {mod} 10)}.

I think what GP is saying is: Just because it is a number (that has a checksum built on it being a number), does not mean most programmers should treat it as one; Treat it as an opaque string. If you need to validate it, use a character by character (not digit by digit) Luhn algorithm; Work on ASCII digits, not numbers.

The issue is that many beginner (and some experienced) programmers treat what should be opaque strings as numbers and throw them into a 32/64-bit integer, or worse, a double precision float (in JavaScript). This can result in data corruption if not done carefully. Then, when something comes in to challenge the programmer's expectations, the program breaks. For example, ZIP/postal codes are 5 numeric digits in the US, but in CA, they're of the form "A1A 1A1" (notice the space and letters). JavaScript's `parseInt` will return NaN on a Canadian postal code. Another one is house numbers; They look numeric, but can have letters or even fractions(!) in them.

The first line is revealing; "contains" is not an operation usually performed on numbers.

Does the number 21 "contain" the number 2? Not in a meaningful sense.

However, the string "21" definitely contains the substring "2".

I’m not sure how it’s taught now, or how it might vary by teaching method, but the way I learned multiplication and division definitely treated the number 21 as “containing” the digit 2. I agree with the conclusion that a CC identifier should be treated as a string, but I don’t find this reasoning to be a compelling argument for that conclusion.

It contains the digit 2, but not the number 2. It's a string of digits, not a singular number.

But that’s the difference isn’t it? In a number each digit represents groups of powers of ten. The number of hundreds, thousands, etc in the number.

The digits in a credit card number are meaningless. They have no relation to each other. If you choose two digits next to each other one doesn’t represent groups of 10x as much as the other digit. Or any other quantity.

The digits are effectively just symbols, not quantities like in a mathematical representation.

That excerpt is clearly describing operations on the digits that compose the string and not arithmetic on the CC number as a single integer.

the digits you parse out of a credit card number are used in a numerical algorithm. That's not the same thing at all.

Vehicle identification numbers, which follow an international standard, also have a check digit, even though they contain alphabetic characters.

ISBN codes too - checksum is base 11 so can be represented by a digit 0-9 or an ‘X’ in the final place.