Article overview

Format the 'Expiration Date' Fields Exactly as the Credit Card (40% Get it Wrong)

· By · 5 comments ·

Formatting the expiration date fields in your payment form to match the design of most credit cards allows for easier comparison.

This is the 6th in a series of 8 articles on checkout usability that combine findings from our checkout usability study and benchmark of the 100 largest e-commerce sites.

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.

Macy's approach with month names and 4-digit year makes it needlessly difficult for the customer to match the values in the virtual fields with those on the physical card.

Poor implementation: how not to format your expiration date fields.

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 behavior was confirmed in our recent mobile e-commerce usability study as well.

A screengrab from our mobile e-commerce study of a subject interacting with month names.

Here a test subject is confronted with month names on Macy’s mobile site, so the subject starts counting the months as he wants to be completely sure which month name the “07” digits on his credit card corresponds to.

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.

Two digits for month and year both – the way it's printed on most cards.

Net-a-Porter formats the expiration date values to match the way they are printed most credit cards. (Note: month/year labels would improve this implementation.)

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.

Appending the month name to the month digits is also an acceptable implementation.

Hayneedle postfix the month digits with the month name. During our usability tests we’ve found this to be an acceptable way to format the month values too.

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.

Adding month/year labels below the expiration date fields further clarifies the values represented.

FTD makes it absolutely clear what the drop-down values represent by adding “Month” and “Year” labels below each field.

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.

Adding a forward-slash between the expiration date fields will help further the resemblance between card and screen.

Safeway adds a forward-slash to further increase the resemblance to the customer’s card layout.

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.

Note: by using text fields instead of drop-downs (see Aéropostale and CVS) you can of course ignore most of the formatting concerns outlined in this article as the user can simply type the values as they are printed on her card.

However, such implementation has problems of its own with increased chances of mistyped input and complex server-side logic to decode the many different types of input formatting customers may use.

Article series

  1. Don’t Use ‘Apply’ Buttons
  2. Don’t Require Seemingly Unnecessary Information
  3. Visually Reinforce Your Credit Card Fields
  4. Accordion Style Checkouts – the Holy Grail of Checkout Usability?
  5. Why Your Checkout Process Should Be Completely Linear
  6. Format the ‘Expiration Date’ Fields Exactly as the Credit Card
  7. Add Descriptions To Checkout Form Labels
  8. A Holistic View on the Current State of Checkout Usability

Jessica Enders October 24, 2012 Reply to this comment

Don’t you just slap your forehead that articles like this even need to be written? I empathise!

But on a more serious note, do you know if it would be possible to use the card number to detect what card type it is (i.e. American Express, Visa, Mastercard etc) and then, knowing that, format the date fields to match exactly as on the card? Obviously this would be the ideal with all the trimmings – so not /necessary/ – but I’m curious whether it’s possible.

Christian, Baymard Institute October 24, 2012 Reply to this comment

Hi Jessica,

Yes it is possible to detect the card typed based on the first 6 characters of the card number (called the IIN range). E.g. VISA start with 4. Most AMEX 34 or 37 and so on. But the IIN range contains much more info than that. It is also tied to the issuing bank.E.g. a card starting with “454305” would be a VISA card issued by Royal Bank of Scotland.
Where your idea gets a bit more difficult to execute is knowing exactly how each issuing bank format their expiration date and then tie that to their IIN range. (Someone should do such a list.. you, me, the card organizations? – is it worth it?)

But on a more basic level you could use the IIN range to change the description for the security code field accordingly. As you know VISA and MC is 3 digits on the back, AMEX is typically 4 on the front. With clever use of the IIN range customers entering a VISA card number won’t see a Security code form description that reads “VISA/MC: 3 digits on the back. AMEX: 4 digits on the front” but only what applies to them, and vice versa. Like this:

Martin Sansom October 24, 2012 Reply to this comment

A superb article – one thing that isn’t clear though in your article is whether payment cards in America use the US standard way of displaying at date rather than the UK version.


US = Month, Day, Year
UK = Day, Month, Year

There are many websites which allow users to switch prices to their preferred currency, but I’m guessing that 99% of those sites fail to switch the date layout at the same time.

Does your research indicate whether this could be a problem, or are users smart enough to figure it out?

I’m assuming that labelling the input boxes helps, but many people would just follow blindly what it says on their Visa card.

Christian, Baymard Institute October 24, 2012 Reply to this comment

Hi Martin,

Great question. The credit card expiration date is for most cards only a month and a year. And luckily in both the US and UK format you mention the year comes last, so MM/YY won’t be a problem in that regard.

Outside the context of credit card forms you are however on to a great point. We’ve recently seen a test subjects order a flight for a completely wrong date (!) because the site used US format (MM/DD/YY) and the subject was used to DD/MM/YY. For this reason we’d recommend that you always write the month as a name whenever you display a specific date (January 5th, 2012 instead of 05/01/2012 or 01/05/2012).

Joe December 7, 2012 Reply to this comment

Thank you for this article! And thank you Jessica ( for bringing it to my attention.

I ask people all the time if they notice this but to be honest, they tend to gloss over it. They’re focussed past it, for when the site confirms the transaction and they can get on with their lives. However, when testing sites in a controlled environment I do get people asking why it is asking for a name-month when the card is a number-month. I can understand someone thought it might be helpful but it is clearly a case of “thought it might help” instead of “proved it might help”. Your analysis clearly shows it doesn’t help.

To be exact, the form isn’t asking for the “month” at all, it is looking for a value from you that it can supply to the payment gateway that helps that gateway process the order. So if it has 03/13 on the card, we really should be capturing 03/13 in the form, regardless of all these other influences. it could equally be supplying two letters, what matters is the process requires two numbers so we should comply with that. The separator is a moot point, since we don’t need to enter that and can regex it out of the way anyway.

Asking the user to translate 06 to 6 – June is completely unnecessary and in some cases, interferes with the process.

Out of curiosity. how does the 60% who use one of your two optimal solutions break down? I’m hoping it is a majority for number only, but not holding my breath.

Post a comment!

Close overlay