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 on

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.