About Me!
This blog is about my musings and thoughts. I hope you find it useful, at most, and entertaining, at least.
Other Pages
Presence Elsewhere
Everyday Numbers 1: Credit Card Numbers
Date: 2013-01-22
Tags: everyday_numbers credit_cards
Your credit or debit card is something you probably use everyday. That 16-digit number is the embodiment of a few different numbers.
| X | XXXXX | XXXXXXXXX | X |
| MII | PAN | C | |
| IIN | |||
MII
MII, or Major Industry Identifier, is defined by ISO/IEC 7812 The list is as follows:
| MII | Issuer category |
|---|---|
| 0 | ISO/TC 68 and other industry assignments |
| 1 | Airlines |
| 2 | Airlines and other future industry assignments |
| 3 | Travel and entertainment and banking/financial |
| 4 | Banking and financial |
| 5 | Banking and financial |
| 6 | Merchandising and banking/financial (Discover) |
| 7 | Petroleum and other future industry assignments |
| 8 | Healthcare, telecommunications and other future industry assignments |
| 9 | 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
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:
| IIN Range | Network |
|---|---|
| 4 | Visa |
| 51-55 | MasterCard |
| 6011,622126-622925,644-649,65 | Discover Card |
| 34,37 | American Express |
For instance, all PNC Debit cards begin 4430.
PAN
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.
C, Luhn Checksum
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
- 09 ↔ 90
- 22 ↔ 55
- 33 ↔ 66
- 44 ↔ 77
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:
- Counting from the check digit, which is the rightmost, and moving left, double the value of every second digit.
- Sum the digits of the products (e.g., 10: 1 + 0 = 1, 14: 1 + 4 = 5) together with the undoubled digits from the original number.
- If the total modulo 10 is equal to 0 (if the total ends in zero) then the number is valid according to the Luhn formula; else it is not valid.
CVV and CVV2
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.
Magnetic Strip
The black strip on the back of your credit card is a magnetic strip. They use ISO/IEC 7813 and can be read any magnetic card reader, or at least every one I tried.
Format:
Track 1:
- Start sentinel — one character (generally ‘%’)
- Format code=“B” — one character (alpha only)
- Primary account number (PAN) — up to 19 characters. Usually, but not always, matches the credit card number printed on the front of the card.
- Field Separator — one character (generally ‘^’)
- Name — up to 26 characters
- Field Separator — one character (generally ‘^’)
- Expiration date — four characters in the form YYMM.
- Service code — three characters
- Discretionary data — may include Pin Verification Key Indicator (PVKI, 1 character), PIN Verification Value (PVV, 4 characters), Card Verification Value or Card Verification Code (CVV or CVC, 3 characters)
- End sentinel — one character (generally ‘?’)
Track 2:
- Start sentinel — one character (generally ‘;’)
- Primary account number (PAN) — up to 19 characters. Usually, but not always, matches the credit card number printed on the front of the card.
- Separator — one char (generally ‘=’)
- Expiration date — four characters in the form YYMM.
- Service code — three digits. The first digit specifies the interchange rules, the second specifies authorisation processing and the third specifies the range of services
- Discretionary data — as in track one
- End sentinel — one character (generally ‘?’)
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?
Credit Card System
This section isn’t about credit card numbers, per say, but about how they are processed.
There are 2 stages for a transaction
- Authorization – Asks bank if money is available and to put it on hold and if the address is correct
- Capture – Tells bank to transfer the money
There are also 7 major players in a credit card transaction:
- Customer – The person making the purchase
- Merchant – The person fulfilling the purchase
- Gateway – Converts nice, HTTP, SOAP, JSON, or XML interfaces into the binary protocol used by the credit card network. Also provides other services such as Tokenization, which allows the Gateway to store a credit card number, and the Merchant to store an opaque token that can be used for later transactions.
- Processor – Converts binary protocol used by the credit card network and forwards it to the correct Issuer. Also deals with reporting and sending Merchant data to the Issuer.
- Issuer – The organization that Issued the card. Commonly the same as the credit card network (e.g.:VISA, MC, Discover, AmEx).
- Issuing Bank – The bank backing your credit or debit card.
- Merchant’s Bank – Bank used by the Merchant and will receive money from the Issuing Bank
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:
- Merchant collects information
- Merchant sends information with an Authorization (and Capture, normally online) to Gateway
- Gateway selects the correct Processor and forwards Authorization
- Processor verifies information and sends Authorization to appropriate Issuer
- Issuer decides to Accept or Decline the Authorization. (If Accept, it places the money on hold)
- Response bubbles up to Merchant.
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
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:
| AVS Code | Meaning |
|---|---|
| A | House Number Matches, but not ZIP |
| N | Nothing Matches |
| X | House Number and ZIP Match |
| Z | ZIP Matches, but not House Number |
| S | 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.:
- 45 S Walnut Ave
- 45 South Walnut Ave
- 45 S Walnut Avenue
- &c
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.