This blog is about my musings and thoughts. I hope you find it useful, at most, and entertaining, at least.
Your credit or debit card is something you probably use everyday. That 16-digit number is the embodiment of a few different numbers.
MII, or Major Industry Identifier, is defined by ISO/IEC 7812 The list is as follows:
|ISO/TC 68 and other industry assignments
|Airlines and other future industry assignments
|Travel and entertainment and banking/financial
|Banking and financial
|Banking and financial
|Merchandising and banking/financial (Discover)
|Petroleum and other future industry assignments
|Healthcare, telecommunications and other future industry assignments
|For assignment by national standards bodies
If the major industry identifier is 9 the next three digits are the numeric-3 country code from ISO 3166-1.
Most people won’t see other MIIs, but they’re out there. Most notably, take a look at fuel or fleet cards for vehicles,e.g.: ZipCar Gas Car in the driver’s visor. I’m not familiar with the computer protocol for use for those though.
IIN, or Issuer Identifier Number, is the first 6 digits, including the MII, of the credit card number. This number is used to identify the issuing bank and credit card network. Previously IINs were called BINs, Bank Identification Numbers, but that usage isn’t as common anymore.
The list of official IINs isn’t public information, but there are many lists that people have collected over the years. Three I’ve used in the past, but make no claim or warranty for, are IIN Base, Bin DataSet, and IIN Database.
As mentioned earlier, the IIN also embeds the credit card network. The ranges for a variety of networks can be found all over the web and in the links above. Some common ranges for the US are:
For instance, all PNC Debit cards begin 4430.
PAN, or Primary Account Number, is the actual account number at the issuer identified by the IIN. The PAN can be from 8 to 12 digits long (Yes, not all credit card numbers are 16 digits long.)
This number is, for all intent and purpose, random and has no global meaning beyond being an opaque ID.
The Luhn Checksum is used by almost all issuers (I haven’t ever seen a card in the wild that didn’t have it, but every table of issuers I’ve seen assures me there is one or two issuers who don’t).
The checksum is used to validate a credit card number before sending it to a remove server (more on that later). The Luhn Checksum can verify many transpositions and substitutions. It does have limits, and cannot detect
There are more complex methods, but the algorithm’s simplicity is easy to implement on limited hardware, or mechanically, as it was in Patent 2950048 from 1960.
There are 3 steps to check a Luhn Checksum:
The CVV and CVV2, for Card Verification Value, are values used to verify card-present (CVV) and not-present (CVV2) transactions. It matters because card-present transactions are billed at a lower rate to the merchant. The CVV is stored in the magnetic strip, and the CVV2 is printed on the back of the card. The CVV and CVV2 are generated from the PAN, IIN, Expiration Date, and encrypts that value with 3DES and a key specific to that run of cards.
Since the encryption keys are only known to the Issuer, in theory it should be extremely difficult to brute-force a CVV or CVV2. This is why they are used to validate transactions, because they should only be known if you have the card. It is against most, if not all, processing agreements to store this value for this reason.
NOTE: There are data integrity checks, Longitudinal redundancy check, but the data stored on-card is not returned to the user by the reader.
Example Track 1 and 2:
%B1234567891234567^SMITH/JOHN ^15024041234567891234? ;1234567891234567=152024041234567891234?
This section isn’t about credit card numbers, per say, but about how they are processed.
There are 2 stages for a transaction
There are also 7 major players in a credit card transaction:
Authorizations happen immediately, Captures are batched for midnight, Processor-time, usually.
Why is this separated? Think of when you go to a restaurant, and they run your card and then have you sign it. They first authorize the card to see if the money is even in your account. If it is, then you can add tip and sign the bill (which is only ever needed if you dispute the transaction). Note! This means that the capture amount and authorization amount don’t have to be the same.
Also, when you use your credit card at a gas pump, depending on the card type, will place an authorization on your card for some amount of money, around $50 if I recall correctly. This is to make sure that you can’t get the gas and use a bum card.
When you place a transaction the following steps occur:
Now, if the response was Accept, then the Gateway places the Capture in the next batch processed. Once it’s processed, the Issuing Bank will transfer the money it placed a hold on to the Merchant’s account.
Also, every time a call is made, it costs the merchant money. The Merchant->Gateway and Gateway->Processor costs alone can be upwards of $0.15 to $0.25 or more a call (combined). This is why using the Luhn Algorithm is important on the merchants side. Those quarters add up, fast.
Speaking of payment, once a Capture is complete, the Merchant is billed a fixed amount (around $0.25) in addition to a percentage (2% to 5%) depending on the card type. The cards that give rewards cost the merchant additional money to accept. Those points are paid for by someone: the merchant!
AVS, or Address Verification System, is a system used when doing an Authorization to verify the house number and zip code, and sometimes name given during a transaction. The return codes can be found all over the net, so I won’t repeat them all here. They are all single letter or number codes, with some of the most common being:
|House Number Matches, but not ZIP
|House Number and ZIP Match
|ZIP Matches, but not House Number
|Bank does not support AVS
Note, only the house number is checked. This is because of the variability in how street names can be written. e.g.:
In the above example, only 45 is checked.
I was told that the reason names aren’t checked most of the time is because of the possibility of issuing the same PAN to two people (e.g.: husband and wife) but with different names on the cards and some of the systems from the 80’s can’t handle multiple names per PAN.
The S code is commonly returned by down systems (instead of R, system down) or for international banks.
Balancing which transactions to accept based on the AVS response is tricky. There is no real perfect solution. I’ve seen cases where an attacker had a full credit card number, CVV2, ZIP, but not house number. I’ve seen people mistype their house number, multiple times. I’ve even seen, more, much much more, than I wanted to, banks who had a wrong or old address on file and the customer couldn’t verify their address at all.
A complexity to this is that an Authorization will hold the money on an account even if the Merchant rejects the transaction because of the AVS code (or any other reason). At this point, the money is on hold for at least a day at the customers bank, the Issuing Bank. The Merchant then needs to do a “Reverse Authorization” to remove the hold; however, the Issuing Bank doesn’t have to respect that request and can continue to hold the money.
To overcome this, a lot of merchants began doing $1 Authorizations. This is why you’ll see one or two $1 charges being held that go away without actually becoming a charge. Some Issuers (VISA, MC, Discover), not the Issuing Bank, take issue with this and have started to fine Merchants that abuse it. A solution to this, that some Issuers and Processors support, is doing a “$0 Authorization.” This essentially puts no hold on the account at the Issuing Bank, but does the AVS check. An Authorization for the correct amount is still necessary to do a Capture, however.