A card expiry test checks whether a payment form accepts or rejects a card based on the expiration month and year a customer enters. Valid future dates should pass, expired dates and malformed entries should fail, and the result should hold true on both the client and the server. Developers run these checks in a processor sandbox with published test card numbers, never with real card data.

more on this topic

What a card expiry test is actually checking

The expiry field looks simple, but it sits at the intersection of user input, browser behavior, and payment processor rules. A useful test covers more than one happy path.

Card Expiry Validation Guide

• Format handling. Does the form accept MM/YY and MM/YYYY, or only one of them? Does it reject letters, symbols, and empty values?
• Month range. Months 00 and 13 are invalid. Months 1 through 12 are valid, with or without a leading zero.
• Expired versus current month. A card is valid through the last day of its expiry month, so a card marked 09/26 is still good during September 2026.
• Two-digit years. The form needs a consistent rule for mapping 26 to 2026 and 85 to 1985 or 2085.
• Server-side repetition. Client checks are for convenience. The server must run the same validation, because anyone can bypass the browser.
• Clock and time zone. Expiry validation that depends on the local device date can disagree with the processor's date.

Edge cases worth adding to a test plan

Most bugs in expiry handling show up at the boundaries. Build a small table of inputs and expected results before you start.

expiry test card

1. Past year with a valid month, which must decline as expired.
2. Current month and year, which should pass until the month ends.
3. Next month, which should pass.
4. Month 00, month 13, and negative numbers.
5. Whitespace, slashes in the wrong place, and pasted text like 09 / 26.
6. Years far in the future, which some processors reject.
7. Empty month with a filled year, and the reverse.

Using sandbox test cards

Payment processors publish test card numbers that behave in predictable ways, including cards that trigger specific decline codes. These numbers are issued for testing only and their expiry dates can be set to any future value in the sandbox. That makes them the right tool for confirming that your form reacts to an expired date the way you expect, without touching a live account.

related article

Keep test data separate from production data. Test cards should live in your repository or test fixtures, and your sandbox keys should never be swapped into a live environment by accident.

Rules that should shape the validation

• Reject any month outside 01 to 12 before you send a request.
• Treat the card as valid through the final day of the expiry month, not the first day.
• Store card data only as far as your compliance obligations allow. Sensitive authentication data such as the CVV should not be retained after authorization.
• Return a clear error message so the customer can correct the date instead of guessing.
• Log the validation outcome, not the card number.

What not to do

Do not run expiry tests with live card numbers or with card data that belongs to someone else. Card numbers, expiry dates, and CVV values that are traded online are stolen records, and using them is a criminal offense regardless of the reason. A card expiry test belongs in a sandbox, with data your processor gave you for exactly that purpose.