# Credit Card Validation in Javascript, Ruby, and C

Jul 3, 2019 · 6 min read

When it comes to programming, each language that I have encountered comes with its unique quirks and virtues. I wanted to compare the difference in syntax of several common languages by writing a credit card checker. The goal of this application is to accept an input of a credit card number and then to identify if a credit card number is syntactically valid. This post is primarily a comparison between a lower level language vs a higher level language. If you would like to see how I implemented the credit card checker, check out my code in C, Ruby, or Javascript here.

Most of us have encountered this screen when trying to make a payment for an online purchase. Usually at the front end, Javascript would handle the validation to check if the credit card is a valid card before a call is sent to the servers. The process of validation checking is based on a checksum algorithm created by Hans Peter Luhn. Here’s a simple break down on Luhn’s algorithm.

## Identifying Credit Card Types

Aside from the checksum, credit card number numbers also identify the type of credit card company. Visa cards start with the number 4. MasterCards start with the number 51, 52, 53, 54, or 55. American Express starts with the number 34 or 37.

# The Big Picture

The solution can be broken down into two parts:

1. Check if the card number is valid.
2. Identify the type of credit card.

Let’s take a look at the syntax for C and walkthrough the code.

# Card Length Validation

To check if the card number is valid, there is a preliminary check that we can check for before calculating the checksum. We know that a credit card number can only be either be 13, 15, or 16. We can do that with a simple while or for loop.

The user’s card number is stored in the variable card number and on each iteration of the length of the number the last digit will be removed and counted. The count of the length of the number will then be checked with if it is either 13, 15, or 16 digits.

Javascript and Ruby both have higher order functions that simplify the process of determining the length of the variable. Essentially, under the hood of the method or function length a similar process is being utilized.

# Checksum Validation

After passing the first test, the next step would be to see if the checksum is valid. Again we, will take a look at the syntax in C.

In this example, the array number is declared and the card numbers are enumerated through and each digit is saved in the array number. The digits that are stored in the array using this method is reversed from the original card number because of the operation of removing the last digit first and storing it in the first index.

Take for example the credit card number is 4012 8888 8888 1881. Using the modulo and divide by 10 method to store the array the resulting array would be [1,8,8,1,8,8,8,8,8,8,8,8,2,1,0,4].

In Javascript, if using a higher order function to convert a number, the number needs to be converted to a string first before using the higher function to convert to an array.

It can be noted that this concept of converting to a specific data type is also similar when using Ruby methods to convert to an array. Ruby and Javascript are similar in that they both require the data to be a certain type and often require coercing the data into a usable type before a higher order function can be used to operate on the data type. You can notice that in my example of Javascript (above)and Ruby (below) that the integers is converted into a string and created into an array and then mapped back into integers.

The checksum for C was cleaner to implement for this reason that there were less type conversions needed to manipulate the data. The array used simple for loops and conditional statements to validate the number.

In the C code above, a new array was created to clone the number array and starting from the second-to-last value the value was multiplied by 2.

The bulk of the validation occurs in this nested if statement. First the length of the card number is determined. Then the arrays digits are added up and checked if the checksum is valid in this one line.

`sumdigit = (number[i] % 10) + (number[i]/10 % 10);`

The type of card is validated by checking the first and second index of the array. In this example, Visa cards start with the number 4.

`cardarray[12] == 4 && accumulator % 10 == 0`

Implementing the validator in ruby and javascript by using higher order functions made it fairly verbose. It would definitely be possible to use the same algorithm for the C program in Javascript and Ruby. However, I wanted to utilize the higher order functions of the language.

To split the array in C, the card number was cloned and multiplied using two for loops. In Javascript, I found that I could use the filter function to separate the initial array into two arrays of every other digits and then a simple map over the first array to double the digits.

The array that has been multiplied by 2 is then summed and added into the array that has not being multiplied using the reduce method. If the checksum passes, then the first two digits of the card array is sliced to check what type of card. The implementation of the card type check is similar to the C syntax. By using a conditional statement the digits of the card array is then evaluated for each type.

# Concluding Thoughts

This post is more of a self reflection on the differences in programming in a lower level language and a higher level language. In attempting to create a credit card checker, I have found that the lower level language syntax to be more concise in getting to the solution, whereas using the higher level language requires data type conversions to use the higher order functions.

If you want to create a credit card checker and test your own code. I used Paypal’s dummy credit card numbers to test the checksum and the credit card type. If you want to check it out here’s the link. https://developer.paypal.com/docs/classic/payflow/payflow-pro/payflow-pro-testing/#credit-card-numbers-for-testing

I’m still learning more about code every day. I would love to hear from you, if you have any tips or suggestions.

Written by

Written by