Format the ‘Expiration Date’ Fields Exactly the Same as the Physical Credit Card (90% Get It Wrong)

Since our earliest days of usability testing at Baymard, we’ve observed users struggle to input their credit card expiration date — a seemingly simple field to complete.

In fact, users are hindered by websites that have expiration date drop-downs where the expiration values don’t match what’s printed on users’ physical credit cards — with a slowed-down checkout, needless validation errors, and abandonments as a result.

The issues caused by websites failing to match expiration date values in the checkout with what’s on users’ physical credit cards were observed during our very first rounds of checkout usability testing dating back to 2010. Since then this behavior has been reconfirmed during all subsequent checkout usability testing, including our most recent Cart & Checkout usability study and our Mobile usability study.

In this article, we’ll discuss the test findings from our Cart & Checkout testing related to credit card expiration date fields. In particular, we’ll discuss:

• Why payment fields are different from other fields users encounter in checkout
• Issues caused by expiration date fields that don’t match what’s on users’ credit cards
• Specifically how not to format expiration date fields
• Observations and considerations on using text fields, rather than drop-downs, for expiration dates
• Three formatting solutions verified to work well

How Payment Fields Are Different from Other Checkout Fields

To understand how a mismatch between how expiration date fields are implemented in the payment interface and how they actually appear on a user’s physical credit card can cause severe issues for users, it’s worth considering the context in which the expiration date will be entered by users.

As users move through a checkout form, they generally type most information from memory — their street address, phone number, etc. The credit card fields, however, are different, as users break their attention from the interface to physically remove their wallet, withdraw their card, and then input the card number, expiration date, and security code seen on the physical card into the appropriate fields in the checkout flow.

Hence, within the payment fields, users are switching their attention from the physical credit card to the checkout interface.

This has consequences for how users input their information. Instead of only having field labels and styling as guides when inputting their other information, when users are inputting their payment information they often have two competing representations of how their data should be inputted — the interface’s fields and what appears on their physical credit cards.

When there’s a mismatch between these two representations, some users will encounter errors as they try to translate from one representation to another.

Issues Caused by Expiration Date Fields That Don’t Match What’s on Users’ Credit Cards

For the vast majority of users, issues caused by a mismatch between the expiration date fields on the interface and the date represented on the credit card are relatively minor, and most users during testing eventually made it past the fields.

However, depending on how the fields are implemented (see next section), many users will slow down or come to a halt at the field as they translate from what they see on their credit card to the expiration date fields, if the two representations don’t match.

For example, when the month field was implemented as a drop-down with only the name of the month displayed, some users during testing were observed to actually count on their fingers as they translated from the numeric representation of the month on their card to what they saw on the interface.

Other users — 24% in our testing — who prefer to use the keyboard to input the expiration date will come to a complete stop, and revert to using the mouse. This interrupts the smoothness of the form-filling process and adds to the time it takes to complete the checkout.

A minority of users, however, will encounter payment validation errors because they’ve inputted the card’s expiration date incorrectly. This can lead to abandonments, depending on the error-recovery experience. For example, are all the payment inputs cleared after the expiration date error? Are users scrolled to the field where the error occurred? Are they provided with clear, highly specific error messages?

During our testing we observed any one of these issues (much less all of them in combination) can be a direct cause of users abandoning a purchase.

How Not to Format Expiration Date Fields

As our benchmark reveals that only 10% of sites format expiration date fields to match what’s actually printed on the card, it’s worth looking at some examples of how the other 90% of sites format expiration date fields, in order of most problematic to least.

How Expiration Date Fields Should Be Formatted

The ISO 7813 standard specifies the characteristics of “Financial Transaction Cards”.

In short, all financial transaction cards should show the card’s expiration date in one of the following two formats: “MM / YY” or “MM-YY” — with the first being the by far most common for credit cards. This represents two digits for the month and two for the year — for example, “02 / 24”.

Adopting this format makes it very easy for users to enter the correct input because they don’t need to translate the numbers on the card to the corresponding month name, or worry if they’re supposed to enter another set of values altogether.

Furthermore, the ISO standard supports keyboard users who will attempt to enter exactly what they see printed on their card using their keyboard (24% in our testing). (Note: of course, users must first be allowed to tab into the month field in the first place to avoid breaking the flow, which is sometimes an issue with custom-designed drop-downs.)

We have however observed one deviation from the ISO 7813 “MM / YY“ standard that has not shown to cause usability issues: if the month name comes after the two-digit month number in the month drop-down (e.g., “03 - March / 24”).

This will still allow users to use the keyboard to input the expiration month and to select the digits as they see them printed on their card.

The expiration date drop-downs can be improved even more by including a forward slash to separate the month and year fields, as well as by adding labels beneath each field (i.e., “Month”, “Year”). These minor design touches will make it even clearer to the user what information is expected in each field.

Considerations When Using Text Fields Rather Than Drop-Downs

During testing, using text fields, rather than drop-downs, for the expiration date fields proved to be somewhat odd to users, with 66% encountering issues or coming to a halt as they encountered what they found to be an unconventional interface.

The test data are however inconclusive as to whether text fields represent a large issue for users or not. As drop-downs have consistently been verified to be a well-performing input type (as long as the “MM / YY” formatting is adhered to), text fields in comparison represent an unverified input pattern through large-scale usability testing.

If there’s still an interest in experimenting with text fields for the expiration date inputs, consider using either two separate fields for month and year (placed right after one another, on the same line, with a forward slash in between), or use a single input field with an input mask. The text fields should also match the expected input length.

Furthermore, the open text fields will need to restrict the user’s input to prevent users from typing invalid values, while still allowing some degree of input flexibility. For example, for the month input “03” and “3” are valid input values; users may also type “1”, which is valid if they don’t type anything else or if they type 10, 11, or 12, but is invalid if they type “13”.

For entering the year, it can reasonably be expected that users will try to type both 2- and 4-digit years. In practice, this makes live inline validation and the use of input masks technically difficult to implement without provoking needless errors, restricting users’ input (e.g., 1-digit months, or 4-digit years), or allowing too-many invalid values.

Don’t Make the Expiration Date Fields Unnecessarily Difficult to Complete

Users shouldn’t face obstacles when entering the most basic information, such as credit card expiration date fields.

Forcing users to translate from what they see on their physical credit card, to the format preferred by a particular site for the expiration date fields, makes it unnecessarily complicated to complete the payment fields.

Adjusting the expiration date fields to match the standard is an example of “low-hanging fruit”: a UX performance boost that’s relatively easy to implement.

Furthermore, attention to these sorts of details is part of what sets “State of the Art” checkout experiences apart from “the rest”.

And yet we find that only 10% of sites use the preferred format for expiration date fields.

This article presents the research findings from just 1 of the 580+ UX guidelines in Baymard Premium – get full access to learn how to create a “State of the Art” cart and checkout user experience.