Boundary-value testing of the month and year pair is the top pick for an expiry date test, and the criteria are narrow: the suite has to catch the errors that produce real declines, it has to run without any live card data, and it has to give the same result on every run. The guidance below covers dates inside your own forms, APIs, and billing logic. The objective is software that handles dates well, not verification of credentials you do not own.
What the test actually checks
Payment cards carry a two-digit month and a two-digit year and nothing else. A card marked 09/28 is treated as valid through the final day of September 2028, so the comparison is always month-level, never day-level. That single fact drives most of the test design. Three layers usually disagree about the value: the browser form, your API, and the tokenized record at the processor. An expiry date test that only exercises the form will miss the mismatch that shows up at renewal time.
Separately, subscription and trial code has a real day component. A trial that starts on January 31 and runs 30 days, or a renewal scheduled for the 31st of a short month, needs day-level tests that card expiry does not.
The core boundary cases
These cases catch the majority of defects in a single pass:
- Current month and current year, submitted on the first and last day of that month
- Previous month of the current year, which must be rejected as expired
- Next month of the current year, which must be accepted
- December to January rollover in both directions
- Two-digit year handling for 00 and 99, to confirm how the century is inferred
- Single-digit month entered as
1versus01 - Month values of 00 and 13, empty strings, whitespace, and non-numeric input
- A far-future year such as 2099, if the field accepts it at all
Manual spot checks versus an automated suite
Manual spot checks
Pros: quick to start, useful for confirming error copy and field behavior, and easy to run before a one-off release.
Cons: not repeatable, weak around month rollovers, and prone to drift as the form changes.
Automated boundary suite
Pros: runs on every commit, covers the month rollover on demand with a frozen clock, and is cheap to extend once the harness exists.
Cons: setup cost up front, requires clock control in the test environment, and can create false confidence if the fixture data does not resemble real inputs.
Recommendation: a small team shipping checkout changes a few times a month should run a short manual checklist plus three automated cases around the month boundary. Any product with recurring billing should run the full automated suite with a frozen clock, because that is where the expensive failures live.
Clock control and timezone
Most expiry bugs are clock bugs in disguise. Freeze the application clock rather than waiting for a real month to end. Test at 23:59 on the final day of a month, and test the same instant in UTC and in the server's local zone. A server that evaluates the month in UTC while the customer sits in a zone that is already into the next month will decline a card that is still valid, and the customer will see a generic failure with no useful detail.
Test data rules
Use synthetic numbers and processor sandbox cards only. Sensitive authentication data should not be retained after authorization, so any fixture that mimics a real card record is a liability rather than a test asset. Generate expiry values programmatically relative to the frozen clock so the suite does not rot, and keep the fixtures in the repository rather than in a shared spreadsheet.
Failures worth hunting
- Off-by-one on the final day of the expiry month
- Two-digit years read as 19xx rather than 20xx
- Month and day transposed when the field format changes between locales
- Renewal scheduled on a day that does not exist in the following month
- Front end and billing layer disagreeing after a card update
Run the boundary list first, add clock control second, and keep the fixtures synthetic. That order fixes the defects that cost money and leaves the cosmetic issues for later.