155

Various online services have different values for maximum year of expiry, when it comes to Credit Cards.

For instance:

  • Basecamp: +15 years (2025)
  • Amazon: +20 years (2030)
  • Paypal: +19 years (2029)

What is the reasonable maximum here? Are there any official guidelines?

BartoszKP
  • 34,786
  • 15
  • 102
  • 130
Art
  • 23,747
  • 29
  • 89
  • 101
  • 1
    The inconsistency across major online stores points pretty strongly towards no official guideline. – Matt Ball Mar 23 '10 at 14:21
  • 10
    I love sites that ask for the expiry year with a simple text input… – Quentin Mar 23 '10 at 14:27
  • 2
    @Quentin it's better than faulty validation that prevents submission, unless the user knows how to use web browser's dev. tools. – Alastair Jan 25 '13 at 14:36
  • 5
    @Alastair — My comment was not intended sarcastically. – Quentin Jan 25 '13 at 14:42
  • 1
    @Quention Fair enough. The ellipsis threw me. :-P For a user, that's clearly the least annoying implementation but from a development/businesses perspective, there'd just be so much erroneous input (and that could cause lost sales). – Alastair Jan 25 '13 at 15:40
  • Google Play also seems to do +20 years if you are curious about mobile apps. – John61590 Jul 19 '17 at 08:56

10 Answers10

74

There is no official guideline as the credit card issuers can choose each when the cards they issue will expire. In fact they have been issuing cards for longer and longer periods of time. If you're trying to determine how far out into the future you should accommodate expiration dates for, err on the safe side and give your customers many years to choose from. That way you future proof your application.

FYI, many credit card issuers do not use the expiration date when determining whether or not to approve a credit card purchase. So if you're worried about an incorrect date being provided the processor will ultimately have the final say on whether the transaction is approved or not so I wouldn't worry about it.

July 2017: Just had an end user with a card that expired almost 50 years from now.

John Conde
  • 217,595
  • 99
  • 455
  • 496
  • 2
    They may approve without a correct code, but they may also charge you higher rates on your transactions that don't have correct codes. – BVernon Oct 22 '14 at 20:04
  • That's only true for AVS and CVV verification. – John Conde Jul 21 '15 at 12:59
  • It's true that most issuers would approve the transaction anyway, HOWEVER not providing the user with the option for the year on his card might discourage him to go on with the transaction. I'd just add 50 years and expect no issuer would intend you to keep a piece of plastic for that long, even if that's a long and a bit of annoying dropdown. – Mauro Oct 22 '15 at 20:24
17

I would either dynamically add +15-20 years to the current date's year OR provide a textbox input for the year (which personally I find faster to type the two digits in than to scroll through a list of years).

Bryan Denny
  • 27,363
  • 32
  • 109
  • 125
  • 7
    unless you're using a mobile phone, maybe. you might prefer swiping through the years. something to consider. – jedmao Jul 22 '10 at 19:17
  • 10
    Good point @sfjedi, and let's not forget that in most browsers you can still key in the number and it'll auto select. – Kevin Wiskia Mar 22 '11 at 19:44
  • 1
    Good point about text input vs select. I have always preferred the text input, but lately with some of my UI testing on Android and iOS, I found that select options seem slightly easier. However, using HTML5's type=number quickly pulls up the numeric keyboard on mobile devices, so that makes things easy too. It think it comes down to validation errors; probably fewer errors with predefined select options. – Clint Pachl Nov 24 '12 at 07:04
  • I'm not sure if this would work good on a mobile device, but what about a dropdown/textbox? You could either enter a value or pick one like normal. – The Muffin Man Dec 08 '14 at 22:36
5

Here's a sampling of the top US online retailers:

RETAILER        WINDOW IN YEARS
Amazon          20
Walmart         10
Apple           NA (TEXT FIELD)
Home Depot      19
Best Buy        10
Target          NA (TEXT FIELD)
eBay            NA (TEXT FIELD)
Google          19
Tom Howard
  • 4,672
  • 2
  • 43
  • 48
4

As a theoretical upper limit, I propose that you do not need to consider more than the expected lifespan of the cardholder. Wikipedia does this in their editorial standards for biographies of living persons:

Any individual born less than 115 years ago is covered by this policy unless a reliable source has confirmed the individual's death. People over 115 years old are presumed dead unless listed at oldest people.

So, in your code, look up the current year, add 115, and use that as your theoretical upper limit to the credit card expiration date. You'll never have to touch that code again.

MetaEd
  • 3,753
  • 1
  • 28
  • 30
  • 2
    I'd say that's very theoretical. Someone with a card that old would have been issued it sometime between their first birthday and the day they were born. And then they would have to live to 115 years! – jimp Feb 02 '12 at 21:15
  • 43
    Boy that's some strong stuff you're guys are smokin'! – Art Aug 10 '12 at 02:13
  • 7
    **SWIM** thought it seemed like a good idea (at the time) to parse Wikipedia's oldest people list to restrict the age input field to that `max` just in case the oldest person used the form once they turned 116... :[ – Alastair Jan 25 '13 at 14:23
  • What about a corporate card which isn't necessarily tied to an individual? In that case, there is no "theoretical" limit. – aaronbauman Nov 24 '15 at 17:31
  • 3
    But @aaronbauman, according to the U.S Supreme Court, a corporation is a person. Thus the card must be only good for 115 years! :-) – Stonetip Jan 08 '16 at 19:27
  • 3
    Credit cards have an expiry date in the MM/YY format. So we're talking about un upper limit of 100 (otherwise you can't tell if YY=22 means the year 2022 or 2122...) – targumon Nov 14 '18 at 23:35
1

Here is a Javascript code snippet you can use to display a customizable list of upcoming years for CC validation:

    var yearsToShow = 20;
    var thisYear = (new Date()).getFullYear();
    for (var y = thisYear; y < thisYear + yearsToShow; y++) {
      var yearOption = document.createElement("option");
      yearOption.value = y;
      yearOption.text = y;
      document.getElementById("expYear").appendChild(yearOption);
    }
          <label for="expiration">Expiration Date</label>
          <span id="expiration">
            <select id="expMonth" name="expMonth">
              <option disabled="true">Month</option>
              <option value="1">Jan</option>
              <option value="2">Feb</option>
              <option value="3">Mar</option>
              <option value="4">Apr</option>
              <option value="5">May</option>
              <option value="6">Jun</option>
              <option value="7">Jul</option>
              <option value="8">Aug</option>
              <option value="9">Sep</option>
              <option value="10">Oct</option>
              <option value="11">Nov</option>
              <option value="12">Dec</option>
            </select>
            <select id="expYear" name="expYear">
            </select>
          </span>
abd3721
  • 1,374
  • 1
  • 11
  • 10
-2
<?php 
$y = gmdate("Y");
$x = 20;
$max = ($y + $x);
while ($y <= $max) {
echo "<option value='$y'>$y</option>";
$y = $y + 1;
}
?>
  • 1
    Just a variation on abovementioned, better to add the years to select and make dropdowns for the month and year selections. Users tend to enter month and year variations differently if just presented with a single text field. – Louis Ferreira Sep 13 '13 at 10:22
-2

If you want a solution that does not yield three-digit years 2100+ you must modulo the date, accordingly you must fill with leading zero for xx00-xx09 years to not get single digit years.

This will be very important starting in 2080.

<?php
    for($i=0;$i<=20;$i++){
        $aktDate = sprintf("%02d", ((date('y')+$i)%100));
        echo "<option value=\"{$aktDate}\">{$aktDate}</option>\n";
    }
?>
Hendrik
  • 141
  • 1
  • 10
-2

While the second example runs twice as quickly as the first you are still getting the date and extracting the year from it 20 times rather than 40 times. A better unrolling of the loop is:

$StartDate=date('Y');
$EndDate=$StartDate+21;
for($i=$StartDate;$i<$EndDate;$i++){
    echo "<option value='".$i."'>".substr($i,2)."</option>\n";

That will be about 20 times faster than the twice as fast example and also addresses a minor bug in the original code in that the year could change from one fetching of the date to the next leading to unexpected, though in this case harmless, results.

user3347790
  • 123
  • 2
-3

After reading the OP's upper validity of 20 years for Amazon, I wrote this simple solution in PHP:

<select name='Expiry-Year'>
    <option value="">yy</option>
    <?php
    for($i=0;$i<21;$i++){
        echo "<option value='".(date('Y')+$i)."'>".(date('y')+$i)."</option>\n";
    }
    ?>
</select>

This has greatly reduced the number of these new-year requests to remove last year from a form.

A leaner version of the loop runs ~twice as quickly:

<select name='Expiry-Year'>
    <option value="">yy</option>
    <?php
    for($i=date('Y');$i<date('Y')+21;$i++){
        echo "<option value='".$i."'>".substr($i,2)."</option>\n";
    }
    ?>
</select>
Alastair
  • 6,837
  • 4
  • 35
  • 29
-7
<script type="text/javascript">
  var select = $(".card-expiry-year"),
  year = new Date().getFullYear();

  for (var i = 0; i < 20; i++) {
      select.append($("<option value='"+(i + year)+"' "+(i === 0 ? "selected" : "")+">"+(i + year)+"</option>"))
  }
</script> 
Rollox
  • 1