# Credit card validation algorithm

## Credit Card Numbers

This code sample demonstrates the algorithm for validating a credit card
number. Almost all credit card companies use the same method for generating
card numbers.

In this method, the last digit of the card number is a checksum. The other
digits are generally used to identify the card company, the financial
institution that issued the card, the customer account number, etc. They follow
whatever coding scheme that particular card company chooses.

The last digit, however, is generated by performing a fixed set of
calculations on the other digits. For almost all credit cards, the Luhn
Formula
is used. This algorithm generates a single digit which is then used
as the last digit of the card number. By performing the same calculations, you
can determine if the number matches the checksum digit.

These may include checking the total number of digits, the number prefix,
etc. The table below shows acceptable values for some of the major credit
cards.

Card Type Prefix Length
American Express 34, 37 15
MasterCard 51-55 16
VISA 4 13, 16

Even when these are correct, it does not guarantee that a given card is
good. The account number may be unused or have been revoked or be over its
limit.

When actually processing a transaction, you’d also want to check the customer
name, expiration date, etc. when submitting it for approval. The code
demonstrated here is really just a first step, meant to help the user by
checking for typos or invalid characters. It can also help you by eliminating
processing on the server for card numbers that are obviously not valid.

#### Algorithm for the Luhn Formula

Here’s how the algorithm for the Luhn formula works. Starting with a given
credit card number,

1 2 3 4 - 5 6 7 8 - 9 0 1 2 - 3 4 5 2

we reverse the number, removing any non-numeric characters, to create a new
string of digits like this (note that the checksum is now the first digit):

2 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1

Now we’ll look at each individual digit. Starting with the second digit in
the string, we double every other number. The others are left alone.

2 5 4 3 2 1 0 9 8 7 6 5 4 3

2 1

This creates a new string of digits shown here:

2 10 4 6 2 2 0 18 8 14 6 10 4

6 2 2

Finally, we go through this new string and add up each single digit
to produce a total. In other words, for this example, we don’t add 2 + 10 + …
but 2 + 1 + 0 + … instead:

2 + 1 + 0 + 4 + 6 + 2 + 2 + 0 + 1 + 8 + 8 + 1 + 4 + 6 + 1 + 0 + 4 + 6 + 2 +
2 = 60

Use your browser’s `View Source` option to see
the full source code.

If this sum is an integer multiple of 10 (e.g., 10, 20, 30, 40, 50,…)
then the card number is valid, as far as the checksum is concerned.

Here is the JavaScript code to sum the digits, where `r`
represents the card number as a string of digits already in reverse order.

`// Run through each single digit to create a new string. Even digits`
`// are multiplied by two, odd digits are left alone.  t = "";`

```for (i = 0; i < r.length; i++) {c = parseInt(r.charAt(i), 10);

if (i % 2 != 0)

c *= 2;

t = t + c;

}

// Finally, add up all the single digits in this string.

n = 0;for (i = 0; i < t.length; i++) {

c = parseInt(t.charAt(i), 10);

n = n + c;

}```

Once the sum is found, the code checks to see if it’s an even multiple of
ten (i.e., n % 10 leaves no remainder).

```  // If the resulting sum is an even multiple of ten (but not zero), the  // card number is good.  if (n != 0 && n % 10 == 0)return true;

else

return false;

}```

#### Programming Note

You may have noticed that the checksum digit (2) is included in the sum.
Rather than adding up the other digits and calculating the valid checksum value
for comparison, it’s included in the total to save some programming steps.

In other words, if you were creating a new card number and wanted to find
the right checksum digit, you’d total up the other digits as shown above except
that you wouldn’t have the initial digit (2).

1 + 0 + 4 + 6 + 2 + 2 + 0 + 1 + 8 + 8 + 1 + 4 + 6 + 1 + 0 + 4 + 6 + 2 + 2 =
58

Using the total (58) you’d take the next highest number that is evenly
divisible by ten and subtract the total from this to produce the proper
checksum digit (60 - 58 = 2 in this case).

If the total was already an even multiple of ten, say 70, the checksum would
simply be zero.

To save a couple of steps in the code, the checksum digit is included in
the calculation so that the sum should be an integer multiple of ten.

# ASC X12

ASC X12, www.x12.org

Vision

To be the recognized cross-industry forum to build and support electronic data exchange standards, related documents and products that are available for use worldwide.

Mission

ASC X12 brings together business and industry professionals in a cross-industry forum to develop and support electronic data exchange standards and related documents for the national and international marketplace to enhance business processes, reduce costs and expand organizational reach.

Developing electronic data exchange standards that fulfill intra and cross-industry needs, ASC X12 enhances business processes, reduces costs and expands organizational reach. Today, ASC X12 represents multiple business domains including finance, government, health care, insurance, transportation and many others! Participate in an open, robust committee with 25+ years of experience developing X12 standards widely adopted by companies of all sizes and around the world.

# Quicken Interchange Format (QIF) files

Quicken Interchange Format (QIF) files

The Quicken interchange format (QIF) is a specially formatted text (ASCII) file that enables
Quicken transactions to be moved from one Quicken account register into another Quicken
account register, or to or from other programs that support the QIF format.

Note: For Quicken to translate data from a text file into the Quicken
register as transactions, the text file must be in the QIF format.

Required File Formatting

Each transaction must end with a symbol, indicating the end of entry. Each item in the
transaction must display on a separate line. When Quicken exports an account register or
list, it adds a line to the top of the file that identifies the type of account or list.
Listed below are the header lines Quicken adds to the exported files:

 Header Type of data !Type:Bank Bank account transactions !Type:Cash Cash account transactions !Type:CCard Credit card account transactions !Type:Invst Investment account transactions !Type:Oth A Asset account transactions !Type:Oth L Liability account transactions !Account Account list or which account follows !Type:Cat Category list !Type:Class Class list !Type:Memorized Memorized transaction list

Quicken can be configured to import all transfers, regardless of whether
Ignore Transfers is selected when the file is imported. To do this, add a line to the file
being imported into the Quicken account. Use a text editor or word processor to put the
following line immediately after the header line at the top of the file:

!Option:AllXfr

Items for Non-Investment Accounts

Each item in a bank, cash, credit card, other liability, or other asset account must
begin with a letter that indicates the field in the Quicken

register. The non-split items can be in any sequence:

 Field Indicator Explanations D Date T Amount C Cleared status N Num (check or reference number) P Payee M Memo A Address (up to five lines; the sixth line is an optional message) L Category (Category/Subcategory/Transfer/Class) S Category in split (Category/Transfer/Class) E Memo in split \$ Dollar amount of split ^ End of entry

Note: Repeat the S, E, and \$ lines as many times as
needed for additional items in a split. If an item is omitted from the transaction in the
QIF file, Quicken treats it as a blank item.Items for Investment Accounts

 Field Indicator Explanation D Date N Action Y Security I Price Q Quantity (number of shares or split ratio) T Transaction amount C Cleared status P Text in the first line for transfers and reminders M Memo O Commission L Account for the transfer \$ Amount transferred ^ End of entry

Items for Account InformationThe account header !Account is used in two places, at the start of an account list and
the start of a list of transactions to specify to which account they belong.

 Field Indicator Explanation N Name T Type of account D Description L Credit limit (only for credit card account) / Statement balance date \$ Statement balance ^ End of entry

Items for a Category List

 Field Indicator Explanation N Category name:subcategory name D Description T Tax related if included, not tax related if omitted I Income category E Expense category (if category is unspecified, Quicken assumes expense type) B Budget amount (only in a Budget Amounts QIF file) R Tax schedule information ^ End of entry

Items for a Class List

 Field Indicator Explanation N Class name D Description ^ End of entry

Items for a Memorized Transaction ListImmediately preceding the ^ character, each entry must end with one of the following
file indicators to specify the transaction type.

KC

KD

KP

KI

KE

With that exception, memorized transaction entries have the same format as regular
transaction entries (non-investment accounts). However, the Date or Num field is included.
All items are optional, but if an amortization record is included, all seven amortization
lines must also be included.

 Field Indicator Explanation KC Check transaction KD Deposit transaction KP Payment transaction KI Investment transaction KE Electronic payee transaction T Amount C Cleared status P Payee M Memo A Address L Category or Transfer/Class S Category/class in split E Memo in split \$ Dollar amount of split 1 Amortization: First payment date 2 Amortization: Total years for loan 3 Amortization: Number of payments already made 4 Amortization: Number of periods per year 5 Amortization: Interest rate 6 Amortization: Current loan balance 7 Amortization: Original loan amount ^ End of entry

Examples of QIF filesNormal Transactions Example

 Transaction Item Comment (not in file) !Type:Bank Header D6/ 1/94 Date T-1,000.00 Amount N1005 Check number PBank Of Mortgage Payee L[linda] Category S[linda] First category in split \$-253.64 First amount in split SMort Int Second category in split \$=746.36 Second amount in split ^ End of transaction D6/ 2/94 Date T75.00 Amount PDeposit Payee ^ End of transaction D6/ 3/94 Date T-10.00 Amount PAnthony Hopkins Payee MFilm Memo LEntertain Category AP.O. Box 27027 Address (line 1) ATucson, AZ Address (line 2) A85726 Address (line 3) A Address (line 4) A Address (line 5) A Address (line 6) ^ End of transaction

Investment Example

 Transaction Item Comment (not in file) !Type:Invst Header line D8/25/93 Date NShrsIn Action (optional) Yibm4 Security I11.260 Price Q88.81 Quantity CX Cleared status T1,000.00 Amount MOpening Balance Memo ^ End of transaction D8/25/93 Date NBuyX Action Yibm4 Security I11.030 Price Q9.066 Quantity T100.00 Amount MEst. price as of 8/25/93 Memo L[CHECKING] Account for transfer \$100.00 Amount transferred ^ End of transaction

Memorized List Example

 Transaction Item Comment (not in file) !Type:Memorized Header line T-50.00 Amount POakwood Gardens Payee MRent Memo KC Check transaction ^ End of transaction