[JulianMorrison]

It's honestly really important NOT to treat a credit card "number" as a number. It is an essentially text string made out of digits. It doesn't have any of the equalities or operations a number has. 01234 != 1234 and so forth.

[Closi]

IMO here you are mixing up what a 'number' is from a programmer's perspective, to what a number is from a User / UX perspective.

We want a user to just be able to input numbers and not letters. Yes, that is a string, but from a user experience perspective we are going to ask them to input numbers / sets of numbers.

This is important, because if they just make it a regular text field then mobile phones will show the full keyboard which makes inputting long numbers very difficult.

[xupybd]

Yes but entering 0123 and 123 results in something very different if it's a string and exactly the same if it's a number.

Anything that can have and needs to retain leading zeros is a string. That string can be restricted to 0-9 and would benefit from the numeric keypad.

https://stackoverflow.com/questions/6178556/phone-numeric-ke...

[andi999]

even worse, sometime 011 and 11 is very different even as a number. Some function from php if it converts strings to numbers, considers a trailing 0 as octal representation. Probably intval without base: https://www.php.net/manual/en/function.intval.php

[darrenf]

That would be a leading 0, not a trailing 0! :)

[andi999]

of course!

[Closi]

> That string can be restricted to 0-9 and would benefit from the numeric keypad.

Yes, that’s the whole point of the original article - that up until now browser support was insufficient to roll this out on a government website.

I’m aware of what happens if you save a string of numerics into an integer. It’s still entering a number from a user / ux perspective.

[HPsquared]

Does it hurt anything for the system to add the leading zeros?

(e.g. a CC number input and stored as "1" and displayed as "0000 0000 0000 0001" - an extreme example I know)

[spiffytech]

Some credit card issuers don't use 16 digits (American Express uses 15). And the first digits indicate the card issuer, so if you haven't stored those correctly you don't know how many zeroes to pad with.

In practice, the Wikipedia list of issuer prefixes doesn't show anyone using leading zeroes, so as long as you don't use separate inputs for each number cluster this specific issue probably won't bite you, though others might. IMO it's better to preserve verbatim user input than to capture malformed data and fix it after the fact.

[david422]

Yes because if you need a 16 digit number and the user entered 15 - it's very likely they just missed a number in the middle instead of the system attempting to correct it with a prepended zero.

[nightpool]

Yes, the commenter you're replying to is specifically talking to programmers, and tell them, from a programming perspective, not to treat a credit card number as a number. They're specifically trying to draw people's attention to the distinction you're saying they "mix up". The point is—even if you might call it a number, you cannot use HTML's "number" type or any numeric types in popular programming languages for storing or processing this data. That's the entire point of the article

[JulianMorrison]

IMO there ought to be a specific entry field type for credit card numbers. Plus possibly also one for CVV/CVNs. Security implications plus formatting implications make it neither "a number" nor "plain text". In a card number, the 4 digit grouping should be automatic, like it is on some of the fancier custom input fields.

[Kwpolska]

What security implications do you have in mind? Hiding the number is evil for the 16-digit CC number and still dumb for the expiry date and security code. Also, autocomplete for those fields is something many people want, and is a browser feature. I can’t see anything else security-related that makes any sense to have for CC numbers specifically.

[JulianMorrison]

Having them scraped, or auto memorized and dug out of cache with a tricksy autofill form, or peeked out of RAM, or I dunno... in general being treated as something other than the highly sensitive personal information they are. Financial businesses acting according to the rules of PCI DSS are not allowed to store credit card numbers or CVVs in the clear anywhere. But browsers shrug and treat them like any old text.

Graphically I was thinking of the opposite of hiding the number, but rather making it clear to see by automatic digit grouping and stuff.

[onei]

It's not strictly true to say a credit card number is not a number. It can be validated by Luhn's algorithm which is numeric in nature, but not in such a way that you would treat it as an integer.

[petesergeant]

It's a sequence of single-digit integers, not a number

[mmmmmbop]

That's true for the mathematical definition of number, but not for the commonly used definition of number as "a numeral or combination of numerals or other symbols used to identify or designate" (4b at [0]). A common example would be a document number, which may often be alphanumeric.

[0] https://www.merriam-webster.com/dictionary/number

[nightpool]

That's great. We're clearly talking about the definition of number used by HTML and all major programming languages. Whether a dictionary counts it as a "number" or not is entirely besides the original point—don't use integer or numeric types for storing or processing this data.

[falcor84]

That is to say it's a numeral

[andrewingram]

Yeah. I'd say it's numeric, but doesn't represent a quantity.

[zbuf]

Are any credit cards issued with numbers beginning zero?

I would bet this sort of pragmatic workaround is taking place.

[lsaferite]

Credit Card numbers start with a BIN (Bank Identification Number) that is 6 or 8 digits. The first digit of the BIN is the MII (Major Industry Identifier). The MII of 0 is indeed valid, but seems to be reserved for use by the committee managing the spec? In any case, it's perfectly valid to have a CC# starting with a 0.

[bombcar]

And this is the kind of thing that can get you if you get "too smart" about verifying the number, by assuming that 0 is reserved and will never be used.

We see this with IP addresses where hardcoded assumptions that were wrong or became wrong blow things up. For example, many people didn't realize that 172.* isn't entirely reserved for internal IPs.