Hacker News Reader

Comment by tokyodude | Hacker News Reader

Dumb question. How much longer till we run out of credit card numbers? Sure 1,000,000,000,000,000 (1 quadrillion) is a large number but the actual usable number is smaller isn't it since there is some kind of checksum system

View on HN

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

[1] https://en.wikipedia.org/wiki/ISO/IEC_7812

[2] The official listing is not publicly available https://www.bindb.com/bin-list.html

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).

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.

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.

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 :)

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.

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.

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.

Even if we cut out that the first 2 digits represent the network (i.e. Mastercard/visa) and cut another checksum digit at the end, it leaves us with 1 trillion numbers. That's about 150 for every living human on the planet.

Then factor in that CC numbers have an ~2year expiry date and a 3 digit CCV number, so old numbers can easily be reused.

Further the name of the holder could be added as a key to the number, further increasing reuse.

We won't run out of CC numbers anytime soon.

The key is credit card number + expiry date. Cards can share numbers as long as the expiry date is different.

This isn’t true, the same PAN (Primary Account Number) is never issued to two different accounts. Even if you wanted to solve all the payment routing problems this could cause, it wouldn’t be possible to implement. The expiry date can change while the PAN stays the same, so you’d never be able to gurantee a unique key today stays unique in the future.

I used to work in a bank where we had to specifically implement routines for when visa reused the PANs...

There was a period between the old expiration and the new issue and not common, but it did happen from time to time.

I should have been a bit more verbose. Two accounts won’t have the same PAN at the same time.

Which is notable, but doesn't matter in the context of "running out of numbers"

Seems to matter a lot for IPv4.

Being able to recycle numbers is the difference between "this can work for a few years at full scale" and "this can work forever". IPv4 can't even reach the first level. It can't even give out one address per human.

I'm sure you've seen the idea that an upgrade to IP could have just added another octet or two and changed nothing else. It would have worked pretty well to prevent us running out of addresses, with 40 or 48 bits.

Well, 16 digit credit card numbers are a hair under 50 bits. And full-size 19 digit credit card numbers are a hair under 60 bits. That's plenty. You can give out a million of them to every person. If we couldn't reuse, they would eventually run out. Because we can, they won't run out.

For example, last time mine renewed I found out that AWS didn't record the expiry date. I only have to update the CVV.

No they cannot. Most customers keep the same CC # and get a new expiry and security code when renewed.

Yes you can't "share" numbers (in the sense of 2 people having the same CC number), but what you describe prevents a new number to be needed (so it is one less new number needed)

Where? This is not common practice where I live, in fact, it's the first time I've heard about it. Interesting!

Do you have a debit or credit card account that you've kept open through a few expiration dates? An old card maybe? Compare it to your current one.

It's always a new number. Shortly before the cards expire, you're issued a new one. That's how it's been for me for this whole century.

It's less of a problem because expiry dates add another variable (though I'm not even sure if issuers had to reuse a number with a new expiry date)

Also CVVs won't match even if you reuse the number

Reply on news.ycombinator.com