credit card form “best practices”

Most of us have written HTML forms which accept credit card details. And most of them have been, well…, bad. I say this because most of us and even the big players out there like Visa and Apple and Microsoft and Google don’t even do this right yet.

Portable Devices

Almost everyone’s credit card forms now work well enough for desktop computers but they work terribly for smartphones and iPads (iOS). The reason is that these portables don’t include a full keyboard—what they usually include is an onscreen keyboard that has to toggle back and forth between characters and numbers. And this is where almost all coders make a mistake because they haven’t tested this on other devices.

Card Number <input type="text" name="cc_number" size="16"> (omit hyphens)
Exp. Month <input type="text" name="cc_month" size="2"> (MM)

This type of interface would look fine on a desktop computer since you don’t have to shift the keyboard to get to numbers. But this isn’t the case for an iPad or an iPhone, for example.

In this example website you would think that Visa has enough money to pay for some marketing people who would provide an excellent experience for all their users.

Screen Shot 2016-08-30 at 4.35.56 PM

What happens though when you visit this site using an iPad and start to fill it out? Notice that every field here expects numbers throughout and yet it defaults to the iPad’s character-based keyboard.

<input class="noBorder margin10" name="cardNumber" id="card" size="14" maxlength="16" autocomplete="off" type="text">

The problem here is that type="text". What you’re expected to type in is a number in all of these fields. If we—as the HTML coder—can select the right type then the user won’t have to toggle back and forth. As it is, an iPad user of this website must:

  1. toggle their keyboard to numeric
  2. type in the card number
  3. touch the month field
  4. toggle their keyboard to numeric
  5. type in the two-digit month
  6. touch the year field
  7. toggle their keyboard to numeric
  8. type in the two-digit year
  9. touch the security code field
  10. toggle their keyboard to numeric
  11. type in the three-digit security code
  12. touch the Go button

Obviously, nobody at Visa has ever used this on their iPhone or their iPad. Each of the items in red above are unnecessary and cumbersome for the user and makes for an ugly design.

HTML Input Types

Here is a list of supported HTML input types. Those that are new in HTML5 are marked with an asterisk.

  • text
  • password
  • submit
  • reset
  • color*
  • date*
  • datetime*
  • datetime-local*
  • email*
  • month*
  • number*
  • range*
  • search*
  • tel*
  • time*
  • url*
  • week*

Although you can use the type="number" option for a credit card form like this I have successfully used the type="tel" which works out much better.

Tel, For the Win!

Using the type="tel" option for each of the former text fields would completely change up the Vanilla Visa website’s HTML form. Older browsers would gracefully default back to type="text" and it would behave as it does now. Newer browsers, especially those on portables, would display the classic telephone keypad style of ten numbers which you may then input into the form.

Screen Shot 2016-08-30 at 5.02.32 PM

What’s sad is that on Apple’s own website they also haven’t figured this out yet and they’re the ones who created iOS and should know better.


Adobe PhoneGap


In 2011, Adobe purchased an existing mobile application development framework by Nitobi, branding it at that time with the name PhoneGap.  They’ve since released it into the open source arena as “Apache Cordova” although many of us still refer to it as PhoneGap.  If you’ve ever attempted to create native iOS, Android or Microsoft Phone applications then you’ll enjoy this new multi-platform approach.

Before PhoneGap, you’d have to install a development kit for each of the various platforms you wanted to target.  And then, you’d need to learn the platform language of each major player:  Objective-C or Swift for iOS, Java for Android and XAML with C# for the Microsoft Phone.  Good luck trying to then design and maintain three completely-different collections of phone app code which hope to provide the same functionality.


But now with PhoneGap, you use what you probably already know:  HTML, JavaScript and CSS.  You then either 1) compress your collection of files using a ZIP file and upload this to Adobe’s website or 2) use the popular repository to manage your software changes and then tell Adobe the location of your github.

I’ll add to this that jQuery Mobile does a great job of streamlining some of the work you can do with PhoneGap.  It includes both methods for interacting with the browser’s DOM and a nice collection of CSS for displaying and lining up the widgets your app will need, for example, phone-styled push buttons that are sized correctly for fingers.


An initial set of app code is created from a command-line interface, producing a collection of files you’ll need for your app.  You’ll usually focus on two files within this collection:  config.xml and www/index.html.  The first will configure the name, version and rights that your app will need and the second defines the interface.  Use any editor you’re comfortable with.  And if you’re familiar with the github source code management then this can be useful later when you build your app.

You usually develop with the help of the PhoneGap Desktop App plus a phone-specific version of the PhoneGap Developer App.  The Desktop App reads your code and serves up a development version of your application; the specific Developer App for your phone will allow you to test your code.  As you make changes in your code the Desktop App will send the new version to your phone so that you can instantly see the change.

Up to this point, none of this yet requires any build keys from Apple, Microsoft or in the case of an Android app, your own self-signed certificate.  Since PhoneGap’s Developer App itself is signed, you’re good to go.


The default set of files from PhoneGap comes pre-equipped with the Jasmine test suite built in.  Edit the www/spec/index.js file to modify the default tests, verify that the PhoneGap Desktop App is running and then execute them by bringing up the /spec folder for your application within the PhoneGap Developer App.


When you’re ready to start seeing your application as a stand-alone app you can then build it on the PhoneGap Build website.

You have two choices for pushing your code to PhoneGap Build:  1) compress your files into a ZIP file and upload it or 2) use a repository for your project and tell Adobe that location.

Since phone apps need to be digitally-signed to identify the developer it’s then necessary to upload to PhoneGap Build one or more keys for this purpose.  An iOS app will need an Apple Developer key, a Microsoft Phone app will need a Microsoft Developer key and finally, an Android app uses a self-signed certificate that you can create without Google’s knowledge/consent or paying them a fee (as is the case for the first two platforms).  The PhoneGap Build website provides enough guidance in this area.

Once built, the PhoneGap Build website provides one or more individual binary downloads on a per-platform basis as well as a QR Code scan image that you can use to direct your phone to fetch the appropriate one.