An expiry date test checks whether the expiration date on a payment card is a real calendar month that has not already passed. The dependable version runs on the server, compares a parsed month and year against the current month, and treats the card as valid through the last day of the stated month. Client-side formatting helps the person typing, but it never replaces the server check, because anything entered in a browser can be changed before it reaches your endpoint.

What an expiry date test actually checks

Three separate questions hide inside one field. First comes format: does the input resolve to a month and a year, whether the user typed MM/YY, MM/YYYY, or a bare MMYY string? Second comes calendar validity: is the month between 01 and 12, and is the year a sane four-digit value rather than a stray keystroke? Third comes currency: has that month already ended? A test that answers only one of these questions passes bad input or rejects good input.

The currency rule trips up most implementations. A card marked 09/26 stays valid through September 30, 2026. It does not expire on September 1, and it does not expire on the last day of August. Compare the parsed year and month against the current year and month as integers, and reject only when the card date falls strictly earlier.

The four rules a correct test enforces

1. Normalize before validating. Strip spaces, slashes, and non-digits, then confirm the remaining string has the expected length. Reject empty fields and strings of letters early so later parsing cannot throw.
2. Parse into integers, not strings. String comparison makes "9" larger than "12" and quietly approves expired cards. Convert the month and year to numbers before any comparison.
3. Compute the current month once, in one time zone. Pick the time zone your ledger uses, typically UTC, and derive the comparison month there. A server in one region and a database in another can disagree about what month it is for a few hours.
4. Store one canonical format. Settle on YYMM internally if you mirror ISO 7813 track data, or MM/YYYY in your application layer. Mixing conventions across services is how expiry bugs survive code review.

Edge cases that break naive implementations

• The current month. A card with the same month and year as today is live. Treat equality as valid, not expired.
• Leading zeros. Some languages drop the zero from "07". Decide whether you accept a one-digit month and handle it in the same branch as the padded form.
• Month 00 and month 13. Both appear in fuzzing output and in typo data. Range-check the month after parsing, not during.
• Two-digit year windows. A test that maps "26" to 1926 will reject every live card. Anchor the century window to the current date.
• Whitespace and missing separators. Users paste "12 / 27" and "1227". Both should survive normalization or fail with a clear message.
• Midnight rollover. At the turn of a month, requests arriving seconds apart can straddle the boundary. Compute one timestamp per request and pass it down instead of calling the clock repeatedly.
• Paste into a masked field. Input masks that reformat on every keystroke often corrupt pasted values. Test pasting a full date, not just typing it.

Client-side checks vs server-side checks

These two layers solve different problems, and both belong in a payment form.

Client-side validation

• Pros: instant feedback, fewer round trips, better mobile keyboards when you set the right input type, and native browser autofill support through standard autocomplete attributes.
• Cons: trivially bypassed, inconsistent across browsers, and easy to make stricter than the server so real cards get rejected before submission.

Server-side validation

• Pros: authoritative, testable with unit tests, immune to browser differences, and the only layer your payment processor will ever see.
• Cons: slower feedback, needs its own error mapping so the form can show a useful message, and requires care with time zones.

Recommendation: treat the browser check as a formatting helper and the server check as the decision. Keep the acceptance rules identical in both places so a date that passes in the form never fails at the endpoint.

Test data you can use

Run expiry tests against the test card numbers your payment processor publishes, never against live account data. Stripe, for example, documents test numbers such as 4242 4242 4242 4242 that accept any future expiration date and any CVC, which makes them useful for form and API tests. Processor sandboxes also expose decline scenarios for expired dates, so you can confirm your error handling without touching a real account.

Keep production card data out of test environments. The PCI Security Standards Council is explicit that sensitive authentication data must not be stored after authorization, and that requirement applies to logs, fixtures, and screenshots just as much as to databases.

A manual QA checklist

• Enter a month of 13 and confirm a clear, field-level error.
• Enter 00 as the month and confirm the same handling.
• Enter the current month and year and confirm the form submits.
• Enter the previous month and confirm the form blocks submission with a message about an expired card.
• Paste a value containing spaces and a slash, then confirm it normalizes.
• Submit a one-digit month without a leading zero and confirm the outcome matches your written rule.
• Tab through the field with a keyboard only and confirm focus order and labels behave.
• Run the screen reader and confirm the field announces as an expiration date field with a stated format.
• Submit an empty field and confirm the error differs from an expired-date error.
• Repeat the form submission from the server side with a fuzzed payload to confirm the server rejects what the browser would have caught.

Why the format layer still matters

Expiry validation is small, but it sits on a path where a wrong answer costs real money in declined transactions or accepted stale credentials. Write the parsing rules down, unit test the boundary months, and keep one source of truth for what counts as current. A team that can point to those three things rarely ships an expiry bug twice.