A card expiry test verifies that the expiration date entered on a payment form is formatted correctly, falls within a plausible range, and has not already passed. It is a validation check performed by checkout pages, payment gateways, and developer sandboxes. A card expiry test confirms the date is well formed, not that a card is live or funded, and it should always be run inside an approved test environment.

What a card expiry test actually checks

Expiration dates are short, fixed-format fields, which makes them easy to validate and easy to get wrong. A typical check covers several conditions at once:

  • Format: two-digit month followed by two-digit year (MM/YY), or four-digit year in some markets.
  • Month range: the month must sit between 01 and 12.
  • Not in the past: the date must be the current month or later. A card stays valid through the final day of its expiration month.
  • Reasonable future limit: most systems reject dates more than about 10 to 20 years ahead.
  • Field pairing: the expiry is checked alongside the card number and security code, not on its own.

The Luhn algorithm, which most people associate with card checking, validates the account number only. It says nothing about the expiration date, so a passing Luhn check does not mean the expiry is correct.

Who runs expiry tests

  • Checkout and subscription developers validating form input before an authorization request.
  • QA teams exercising edge cases such as February 29, year rollover, and last-day-of-month cutoffs.
  • Payment gateway sandboxes that simulate approved, declined, and expired-card responses.
  • Support teams confirming a card on file using the last four digits and expiry month.

How the validation logic works

  1. Strip spaces, slashes, and any characters that are not digits.
  2. Split the remaining digits into month and year segments and reject anything that is not numeric.
  3. Check that the month is 1 through 12 and expand a two-digit year into a full year.
  4. Build a date for the last day of that month and compare it with the current date in the gateway's time zone.
  5. If the date is in the past, block submission or return a clear error message.

Time zone handling matters more than people expect. A form that compares against local device time can accept or reject a card a day early near a month boundary, which produces support tickets that are hard to reproduce.

Sandbox test cards

Payment providers publish test card numbers for their sandbox environments. These numbers are not tied to real accounts, and the sandboxes generally accept any future expiration date so developers can focus on form logic rather than date math. Test card sets usually include an explicitly expired date so teams can confirm the rejection path works. Use the numbers your own provider documents, inside that provider's test mode, and never enter a real card into a sandbox you do not control.

Common reasons an expiry test fails

  • The card genuinely expired at the end of last month.
  • The month and year were entered in the wrong order, which happens often with international formats.
  • A typo or autofill error dropped or duplicated a digit.
  • The stored card on file was replaced after a reissue and the profile was never updated.
  • Browser autofill inserted a date from a different saved card.
  • Validation compared against the wrong time zone or used a stale cached date.

Security and legal boundaries

The expiration date is part of cardholder data under the PCI DSS framework, so it needs protection whenever it is stored with the account number. Outside of an authorized sandbox, entering card details that belong to someone else to see whether they work is card fraud, and United States law treats unauthorized use of a payment card as a federal offense. Legitimate expiry testing happens on your own cards, in a provider's test environment, or on synthetic numbers the provider publishes for that purpose.

Quick checklist for reliable expiry validation

  • Accept MM/YY and MM/YYYY, then normalize to one internal format.
  • Validate the month range before doing any date comparison.
  • Treat the card as valid through the last day of the expiration month.
  • Compare against a server-side date, not the visitor's clock.
  • Return a specific message such as "card expired" instead of a generic decline.
  • Test month boundaries, leap years, and empty input before release.
  • Keep test card numbers and live credentials in separate environments.

Does an expired card still work?

No. Once the expiration month ends, the issuer stops approving new authorizations, even if the account itself remains open. Recurring billing on that card typically fails until the customer supplies the replacement card.

Why do some forms accept an obviously wrong date?

Many processors treat the expiration date as a soft check and rely on the issuer to reject a mismatch. That keeps friction low for legitimate customers, but it means client-side validation is a convenience, not a security control.