Designing a User Interface for Credit Card Expiry Dates

Designing a user interface for capturing credit card expiry dates is an interesting, multifaceted problem. To work though this problem, we need to ask three questions:

1. What default values should be used for the expiry date?
2. What are the opportunities for users to make errors when transcribing the expiry date from the card to the user interface?
3. How can we support data entry by reducing the cognitive load on users to help prevent errors?

Two common user interface styles for collecting credit card expiry dates are a pair of text input boxes and a pair of dropdowns. Throughout this article, I’ll refer to these two styles as the text box UI and the dropdown UI.

Text Box UI	Dropdown UI

What should the default value be?

Providing reasonable defaults is a good user interface design guideline. Defaults both minimize the work required by users to enter data into software and explain the user interface by providing example values. Using this guideline, providing a default expiry date seems like a good approach.

The default month can have one of twelve possible values. Although arbitrary, we may choose January because it’s the beginning of the year. In contrast, we need to put more thought into the default year. The oldest valid card will expire in the current year. If the current year is 2015, for example, there are no valid cards that expire in 2014 or before, so our default year value must be at least 2015. If we assume that credit cards have a maximum lifetime of five years, then the newest cards will expire in 2020. This gives a range of years from which to choose the default year: 2015, 2016, 2017, 2018, 2019 or 2020. Inevitably, though, the choice is still arbitrary since none of these years is any more likely to be correct than the others.

Whichever default month and year value we choose, we’ll be correct for only a small number of users that happen to have cards that expire in that month and in that year. But isn’t it better to have a correct default value for some users than for none at all? As the saying goes: even a stopped clock is correct twice a day. Is there actually a disadvantage of providing a default value that only suits a minority of users? Actually, there are two disadvantages, both of which stem from the need for users to change the default value to the correct value.

The first disadvantage of providing a default expiry date is that users must actually notice that the expiry date is incorrect. Since credit card entry form UIs generally ask for the credit card number before the expiry date, after entering the credit card number, users that see the default expiry date may assume that the UI has populated the expiry date based on the card number.

The second disadvantage of providing a default expiry date is that users may have to perform extra work to replace the default value with the correct value. For example, the text box UI requires the user to replace the default text. This text replacement step can be mitigated if the default text is automatically highlighted when users click on the input box or tab into it; the default value will be replaced on the first keystroke. The dropdown UI fairs better in this case because choosing the correct value takes the same amount of work regardless of the current value.

Based on this analysis, I would recommend not using default values that are actual months and years. Instead, use placeholder values that illustrate what data is required. However, before choosing the format of the placeholders, let’s look at the kind of errors users can make when entering expiry dates.

Opportunities for Data Entry Errors

The data entry task is to accurately transcribe the month and year of the expiry date as printed on the card. Users can make syntactic and semantic errors when transcribing data from the credit card to the UI. Syntactic errors occur when users enter values that are not valid; semantic errors occur when users enter valid values that are not correct. The dropdown UI is able to prevent all syntactic errors because the only values available to choose from are valid. However, users can still make semantic errors when they enter the wrong month or the wrong year.

The text box UI is more limited in its ability to prevent syntactic errors. For example, users can enter an invalid month, such as 60, which can occur when users transpose 06 for June. To prevent this kind of error, implementations of the text box UI could disallow users from entering any digit other than 0 or 1 as the first digit in the month input box. Since any positive year is valid, the year input box need only disallow users from entering a minus to prevent year syntax errors. Although the text box UI is able to prevent some syntactic errors, just like the dropdown UI, the text box UI is also unable to prevent semantic data entry errors.

Although we can prevent syntactic errors by using the dropdown UI, we can’t prevent semantic errors. Therefore, we need to design a UI that supports a data entry task that will always be prone to error. To do that, we need to understand the underlying cause of the errors.

Credit cards use a standard expiry date format of two month digits followed by two year digits (MM / YY). However, UIs for capturing expiry dates are far from standard. Whenever the UI differs from this format, there is an opportunity for users to make data entry errors.

The following table lists each variation of the text box and dropdown UIs. The table also lists the translations that users must perform when transcribing the month and year digits from the card to the UI and the comparisons required to validate the transcription.

	Month		Year
User Interface	Translation	Validation	Translation	Validation
	None	Direct	None	Direct
	None	Direct	Enter the 20 prefix before entering the two year digits on the card	Compare the two year digits on the card with the last two digits in the year text box
	None	Direct	None	Direct
	None	Direct	Prefix the two year digits on the card with 20 before selecting the year	Compare the two year digits on the card with the last two digits of the selected year option
	Map from month number on the card to month name in the UI	Map from month number on the card to month name in the UI	None	Direct
	Map from month number on the card to month name in the UI	Map from month number on the card to month name in the UI	Prefix the two year digits on the card with 20 before selecting the year	Compare the two year digits on the card with the last two digits of the selected year option

Supporting the Data Entry Task

The greater the difference between the format of the expiry date on the card and the format of the expiry date in the UI, the greater the cognitive load on users when transcribing and validating their transcription. For example, the following form of the dropdown UI puts the greatest cognitive load on users because it has a different format than a credit card for both the month and year. Additionally, the month dropdown requires users to translate the number of the month on the card to the name of the month.

To support the data entry task, we need to reduce the cognitive load on users. The following forms of the text box and dropdown UIs both match the format of the expiry date on the card exactly. As a result, these UIs place the least cognitive load on users and reduce the likelihood of transcription and validation errors.

To support users when entering credit card expiry dates, I recommend using the following version of the dropdown UI with the default values of MM and YY for the month and year. This version requires no translation for either the month or the year and is able to prevent all syntactic errors.