What a card expiration test actually checks
A card exp test verifies that your checkout form reads the expiration date field, validates it, and passes it to the payment gateway in the shape the gateway expects. It is a form and integration test. It runs in a sandbox with test card numbers issued by your processor. It never touches a live cardholder account, and it never involves a real card number, CVV, or cardholder name.
The test covers four things: input formatting, calendar validity, boundary behavior at the current month, and the payload your server sends to the gateway. A form can accept a date and still fail all four.
Prerequisites
- A sandbox or test merchant account from your payment processor
- The processor's published test card numbers, including their fixed expiration dates
- A staging checkout page wired to the sandbox endpoint
- Access to request logs so you can inspect the authorization payload
Run the expiration date test
- Open your staging checkout and confirm it points at the sandbox gateway endpoint, not production.
- Load the processor's test card list and pick a card whose published expiration date is in the future.
- Enter that expiration date in the form and submit. Confirm the gateway returns an approval response, not a format error.
- Enter a date one month in the past. Confirm the form blocks submission or the gateway declines with an expired card code.
- Enter the current month and year. Confirm the form accepts it, since a card stays valid through the last day of its expiration month.
- Test the input format variants your UI allows: MM/YY, MM/YYYY, MM-YY, and a two digit year. Confirm each one converts to the same value before submission.
- Test month 00 and month 13. Confirm both are rejected at the field level.
- Enter February 29 on a leap year and February 29 on a non leap year. The first should pass, the second should fail.
- Submit with the expiration field blank and with non numeric characters. Confirm both are rejected.
- Open the request log and read the authorization payload. Confirm the expiration date is sent as four digits with no slash and the correct century.
- Check that your logs and database do not retain the CVV or the full card number after the authorization response, as PCI DSS requires.
Common failure modes
The most common defect is a two digit year that gets stored without a century, so 12/29 becomes 2029 on one screen and 1929 on another. The second is a client side check that only looks at the month, which lets an expired card from a prior year through. The third is a timezone mismatch: a server running UTC rejects a card on the first day of its expiration month for users west of the date line.
Keep one test card with a far future date in your regression suite. It stays valid for years and gives you a stable baseline for every checkout change.