Credit Card Validation


When working on app recently, our payment processing provider, communicated to us that unfortunately they support only certain kinds of credit cards.

We didn’t want to let users type card number that is not supported, only to send it to server, and after getting the response, show an error.

If we know what types are supported, we can show the error earlier, and avoid sending any data – making the experience much better for the user.

We tried several frameworks but what we found is that:

  1. most of the frameworks allow passing not correct CC number (e.g. Visa with 11 digits only validates just fine)
  2. all of the frameworks we tested, allow checking credit card type only after all digits are passed

Especially 2. was imoportant for us to improve on. If we know e.g. that all Visa cards start with number 4, why wait until all 16 digits are typed?

Same goes for cards that are not supported. If user types 34 in CC number field, we know it will be American Express card – and if we don’t support it, we can immediately show the error.

I described in more details what I created in a Medium blog post, so please go there for more information.

Or you can go directly to our CCValidator framework GitHub page, and read installation and usage guide, or read short description below.

Installation and usage guide

CCValidator is available on CocoaPods already.

To install it, add to your Podfile:

pod 'CCValidator', '~> 1.0'

Then, use it in your code:

let recognizedType = CCValidator.typeCheckingPrefixOnly(creditCardNumber: numberAsString)
//check if type is e.g. .Visa, .MasterCard or .NotRecognized

or if you don’t need credit card type, and need only to validate CC number correctness, use:

let numberAsString = textField.text
let isFullCardDataOK = CCValidator.validate(creditCardNumber: numberAsString)

Hope that’s gonna be useful for you. We will gladly welcome all contributions and ideas for what we should add to it!

https://github.com/DigitalForms/CCValidator

Related Posts

GitHub Pages and Automatic Deployment

Looking for a free website hosting and automatic deployment after source code changes? Try GitHub pages and Wercker!

Swifty function currying

Function currying is something I wanted to dig into for some time now, and finally I found a good time for it, especially now, after some changes introduced to the syntax in Swift 3.

Pyramid of Doom Updated (Swift 3)

Since last posts about using `let` and `guard`, Swift 3 came out and changed a few things here and there. Let's see what's new!

Dealing with Swift's Pyramid of Doom

Today we continue topic of avoiding Swift's "Pyramid of Doom" that we started in previous post about `guard` statement.

Let and guard statements in Swift

Swift 2 was announced in June, soon to be a year ago. Still, some of the concepts it introduced are new to many iOS developers.