During our usability studies we’ve observed customers needlessly struggle to decipher expiration date fields when the values are formatted differently from the credit card. The solution is of course obvious: format the expiration date values the same way they are formatted on the card. In this article we’ll look at how to do just that.
When benchmarking the top 100 e-commerce sites in the US we found that 40% formatted the expiration date fields in ways that doesn’t match the majority of credit cards out there. Luckily, that also means 60% had chosen one of the two optimal ways of formatting the expiration date fields.
How You Shouldn’t Format the Expiration Date Fields
If the goal is to match the credit card formatting, then you should avoid using month names (with one exception noted later) and the year should preferably be two digits long instead of four. This is because most cards have the expiration date printed as numbers (as defined by ISO7813), and so the correct way to format your expiration date fields is to show numbers only. This minimizes confusion and misreading because the customer can easily verify the value on their screen against the value printed on the physical card.
During our e-commerce checkout test sessions some users started counting the months on their fingers when presented with a “month name only” drop-down to make sure that the “09” month they saw on their credit card did in fact translate correctly to the “September” selected on their screen. This behaviour was confirmed in our upcoming m-commerce usability study as well.
The Optimal Way to Format the Expiration Date Fields
The correct way to format the month field is to use numbers and to prefix all single-digit numbers (i.e. 1 to 9) with a 0, so that they appear exactly as they do on most credit cards (e.g. “03” for March). The correct way to format the year field is to use just two digits, to match the number on most credit cards (e.g. “14” for 2014).
Some card issuers choose to print the expiration date differently so you can’t match every single card out there perfectly – instead the idea is to match the vast majority of them.
The ISO7813 standard specifies the characteristics of “Financial Transaction Cards”. In section 6.2, the standard specifies MM/YY or MM-YY as the correct way to emboss the expiration date on credit cards. Hence designing your expiration date fields to match these values will allow the customer to very easily enter the correct input because they don’t need to translate the numbers on their card to the corresponding month name, or worry whether they’re supposed to enter another set of values altogether.
During our usability test sessions we’ve identified a second acceptable way to format the expiration date fields: you can include the month name as long as comes after the month digits. The test subjects showed no difficulties when month name was appended to the digits so “03 – March” is an acceptable format, but “March – 03” is not (it hurts scannability). When the digits are front-loaded, the immediate value matches what’s printed on most cards which makes it easy for the customer to instantly identify the correct option.
Getting the Details Right
There are a couple of small details you can implement to further improve the design of the expiration date fields.
One thing you can do is add labels below the expiration date fields to explicitly state the value they represent. In fact, some cards have small “Month” and “Year” labels printed below or above the expiration date digits, although it is not as common as the ISO-specified “MM/YY” embossing.
Another benefit of this implementation is that you avoid any confusion as to which field represents months and which represents years – although starting next year (2013), this won’t be an issue for another 80 or so years. (Note: if you’ve opted for the “02 – February” month representation the importance of labeling each field this way of course go down drastically as the value itself will function as an indicator.)
If you’re really looking to perfect the expiration date layout, you can add a forward-slash or dash between the two fields (ISO7813 define both as acceptable, although in our experience the forward-slash is the most common card design). This will further increase the resemblance between the values printed on your customer’s card and the design of your expiration date fields.
This is however not an invitation to go over the top with a skeuomorphic form design and decorate your payment form as an actual credit card. Instead what we’re advocating is that you ensure the values the customer has to select in your payment form match the values printed on her credit card – allowing her to select those values with greater ease and confidence.
To sum-up, let us quickly go over some common formattings and separate the good from the bad.
Bad. How not to format the card expiration fields (yet what 40% of top retailers do):
- March / 2012 · Completely off. Month names are difficult to decipher and year should preferably be two digits instead of four.
- March – 03 / 2012 · Difficult to scan month digits due to varying lengths of the 12 month names.
- 3 – March / 2012 · Month digit isn’t 0-prefixed.
- 3 / 2012 · Month digit isn’t 0-prefixed.
Good. Two optimal ways of formatting the expiration date fields:
- 03 / 12 · This is the most common card layout resulting in 1:1 mapping between virtual fields and physical card, but remember to clearly label each field with “month” and “year”.
- 03 – March / 12 · Adding the month name lowers the chance of mixing up month and year, but this comes at the cost of 1:1 resemblance with the credit card.
Tip: remember to make the “year” range update dynamically so you don’t end up with a ‘2008’ option in year 2012.