A Better Credit Card

This post is content previously published on www.cathmhaol.com

After a few years of working on payment systems, I have grown frustrated with the quality and the interaction of credit card input interfaces. Since I'm being paid to think, I've been thinking about this for a while and I've come up with what I believe is a decent solution.

Of course, building a global card solution is not an easy task - there are a number of credit cards (and debit cards) out there and most have their own data requirements. For example, Visa and Mastercard numbers are generally 16 digits long and can be validated using the Luhn algorithm (what we used to refer to as "double-add-double mod 10 with enfolding"); however, China Union Pay can be variable length (within a set of lengths, actually) and does not use the Luhn algorithm to validate.

Of course there are other things a developer must consider - such as do we need to collect date of birth (some cards require date of birth to check that the user is 18 years old or more) and do we need a full billing address or will just a ZIP code suffice, or is the card like the Solo card, which adds data elements of start date and issue number.

What I came up with is a form that is based on the validation library I developed and is styled like something you might see on a mobile device. Of course it's US-centric, and you would probably want to change the design to fit with your site, but it should be nearly ready to go. To help, there are debug statements listening for error events - you'll want to clean up the code to change those event listeners so that instead of being logged to the Console you're using them to actually let the user know there is a problem.

There are also a few shortcuts that I've taken that make this a little less accessible than what it would otherwise be. For example, using a background color to convey whether a required element is missing or invalid. That should be cleaned up before the code goes into a live environment as well.

That's all there is. One little caveat though - since the document uses HTML5 and CSS3 be sure your DOCTYPE is set to html or IE will give you fits...and that brings me to the final piece you'll probably want to change - you'll want to do something for IE to bring it up to the HTML5 standards.

[Edit: You should also realize this isn't necessarily going to give you everything you may need. For example, you may find that when you do card authorizations you need a person's billing address or the name on the card - those extra bits you'll need to see to on your own. Of course you can easily extend the validation for things like name and address - and I'm hoping to get to an address validator in the near future to make it easier.]

As for the JS library the form is based upon - as with all the JS libraries I've developed, nothing is minified (because you can do that after I've done all the heavy lifting) and everything is commented well enough that most anyone should be able to read the code and the comments and understand exactly what's happening. Of course if you get really stumped, my email address is buried in the library comments, so you can query me if there is something odd.

Finally, I haven't even attempted to zip everything together yet - there's really just not enough there to worry about, so I'm probably not going to do that - but take a look at http://products.cathmhaol.com/prototypes/cc-input/ and let me know what you think.