3 ms·

If you are interested, you can purchase the current specification for the low price of only $68 [0]. Based on wikipedia [1], the first 6 digits are used to ide

If you are interested, you can purchase the current specification for the low price of only $68 [0]. Based on wikipedia [1], the first 6 digits are used to identify the issuer (although from looking at this listing [2], it appears to be standard practise to assign some institutions blocks of IINs, and given that an institution could control multiple IINs, it is probably relatively safe to consider these to be part of the unique card ID. When we start to run out, we will probably see a market for these emerge in the same way we see a market for IPv4 subnets today. The only area of fragmentation where I see potential trouble for secondary markets is the first digit, which is restricted by industry (banking only has 4,5,6); but if it ever becomes an issue, I am sure they will re-purpose the address space of other industries for banking This leaves only the checksum digit itself of deeply problametic for maximum utilization; and that is literally a single digit. [0] I wish this were a joke. https://webstore.ansi.org/Standards/ISO/ISOIEC78122017 https://webstore.ansi.org/Standards/ISO/ISOIEC78122017 [1] https://en.wikipedia.org/wiki/ISO/IEC_7812 https://en.wikipedia.org/wiki/ISO/IEC_7812 [2] The official listing is not publicly available https://www.bindb.com/bin-list.html https://www.bindb.com/bin-list.html

AmericanChopper 8y ago
I don’t think we’ll ever have the same issue with PANs that we have with IPv4. There’s never been a standard length for PANs, they already come anywhere between 15 and 19 digits, and simply tacking more on to the end doesn’t present the same challenges as it would have done with IPv4. A lot of organisations that process payments wouldn’t even have to change anything, and those that did would have a pretty strong insentive to do so (to continue getting paid).
- leejo 8y ago
  The APACS 70 standard allows for a maximum card length of 19 digits, so tacking more digits on the end isn't going to work with current message formats. IIRC ISO 8583 also has the same limits, although that message format is somewhat more flexible than APACS 70 so could probably be tweaked. It would of course require a massive amount of work across the board, so it's very unlikely to happen.
  - AmericanChopper 8y ago
    It wouldn’t actually be across the board though, the number of organisations that actually interact with AS 2805, APACS 70, ISO 8583... is orders of magnitude smaller than the number that have interact with IPv4. I think you’re also overestimating how robust these standards are, I’ve never seen two implementations of ISO 8583 that were the same, and I’ve seen some that would process long account numbers without issue. But the real difference is that every stakeholder has a vested interest in keeping their networks operable. Your average consumer doesn’t know what IPv6 is, or who the IETF are, and won’t take kindly to being told they should spend money to fix a problem they created decades ago. Banks don’t have that issue, and those standards aren’t nearly as entrenched as IPv4 is.
    - leejo 8y ago
      I never saw two implementations that were the same either, it was a particular annoyance, but they all defined the PAN as n..19 IME (and 19 was indeed a rare case generally seen with now defunct/less popular card schemes so there's proabably still room to fill). It's true that the number of organisations that interact with the message formats for sending card transactions is significantly smaller than other things, but we're talking about every single bank, every single PSP, every single embedded card device, and probably many more organisations beyond that, currently in operation today. Given the glacial pace of most banks' IT operations I would not expect them to do be able to achieve this within a time frame of several years or perhaps even a decade. Sure these are not the same challenges as IPv4 and such, but it is in no way a trivial change to tweak a message format that has been in use since before most HN users were born :)
  - Dylan16807 8y ago
    Using all 19 digits is tacking more digits on, for practical purposes. And it really should be enough. With 10^18 numbers you can allocate 1000 numbers per day to each of 10 billion people, and go 10 years between reusing numbers, and still have only a few percent of numbers reserved at any point in time.
- paublyrne 8y ago
  There are a million sites out there with credit card forms with 16 digit validation for Visa and Mastercard, so it wouldn't be entirely painless to introduce extra digits.
  - AmericanChopper 8y ago
    It’s not really the customer facing web apps that would be a problem here. But I can tell you, anybody who’s tried to do validation on credit card numbers has experience with failing at doing validation on credit card numbers.

AmericanChopper 8y ago

I don’t think we’ll ever have the same issue with PANs that we have with IPv4. There’s never been a standard length for PANs, they already come anywhere between 15 and 19 digits, and simply tacking more on to the end doesn’t present the same challenges as it would have done with IPv4. A lot of organisations that process payments wouldn’t even have to change anything, and those that did would have a pretty strong insentive to do so (to continue getting paid).

leejo 8y ago
The APACS 70 standard allows for a maximum card length of 19 digits, so tacking more digits on the end isn't going to work with current message formats. IIRC ISO 8583 also has the same limits, although that message format is somewhat more flexible than APACS 70 so could probably be tweaked. It would of course require a massive amount of work across the board, so it's very unlikely to happen.
- AmericanChopper 8y ago
  It wouldn’t actually be across the board though, the number of organisations that actually interact with AS 2805, APACS 70, ISO 8583... is orders of magnitude smaller than the number that have interact with IPv4. I think you’re also overestimating how robust these standards are, I’ve never seen two implementations of ISO 8583 that were the same, and I’ve seen some that would process long account numbers without issue. But the real difference is that every stakeholder has a vested interest in keeping their networks operable. Your average consumer doesn’t know what IPv6 is, or who the IETF are, and won’t take kindly to being told they should spend money to fix a problem they created decades ago. Banks don’t have that issue, and those standards aren’t nearly as entrenched as IPv4 is.
  - leejo 8y ago
    I never saw two implementations that were the same either, it was a particular annoyance, but they all defined the PAN as n..19 IME (and 19 was indeed a rare case generally seen with now defunct/less popular card schemes so there's proabably still room to fill). It's true that the number of organisations that interact with the message formats for sending card transactions is significantly smaller than other things, but we're talking about every single bank, every single PSP, every single embedded card device, and probably many more organisations beyond that, currently in operation today. Given the glacial pace of most banks' IT operations I would not expect them to do be able to achieve this within a time frame of several years or perhaps even a decade. Sure these are not the same challenges as IPv4 and such, but it is in no way a trivial change to tweak a message format that has been in use since before most HN users were born :)
- Dylan16807 8y ago
  Using all 19 digits is tacking more digits on, for practical purposes. And it really should be enough. With 10^18 numbers you can allocate 1000 numbers per day to each of 10 billion people, and go 10 years between reusing numbers, and still have only a few percent of numbers reserved at any point in time.
paublyrne 8y ago
There are a million sites out there with credit card forms with 16 digit validation for Visa and Mastercard, so it wouldn't be entirely painless to introduce extra digits.
- AmericanChopper 8y ago
  It’s not really the customer facing web apps that would be a problem here. But I can tell you, anybody who’s tried to do validation on credit card numbers has experience with failing at doing validation on credit card numbers.