What a card expiration test verifies
A card expiration test checks whether a payment form accepts, rejects, and formats the expiration date the way your gateway expects. It confirms the field blocks past dates, accepts a date in the current month, handles MM/YY and MM/YYYY, and passes the value to the authorization request in the documented format. This is a functional test of your own checkout code. It does not tell you whether an account is open. Only an issuer, through an authorization request from your processor, can answer that.
Prerequisites
- A sandbox or test mode account with your payment processor
- A published test card number from that processor
- A staging build of the checkout form
- Access to server logs or the processor dashboard for the outgoing request
- A browser or test runner for the input checks
Steps
- Open the checkout page in your sandbox environment.
- Enter a test card number published by your processor.
- Type a past date in the expiration field, such as 01/20.
- Submit the form and confirm it blocks the submission with a message tied to the expiration field.
- Enter the current month and year and submit. A card stays valid through the last day of its expiration month, so the form must accept this value.
- Enter a date one month ahead and submit. Confirm the form accepts it.
- Switch the input between MM/YY and MM/YYYY and repeat steps 3 through 6.
- Submit with the field empty, then with letters, then with a space. Confirm each attempt fails with a clear message.
- Open the outgoing authorization request in your server logs or processor dashboard. Confirm the expiration value arrives as MMYY or whatever format your gateway documents.
- Log each result next to the matching test case before you ship the build.
Edge cases worth covering
- Month 00 and month 13
- A single-digit month such as 1/26
- A year far in the future, such as 12/2099
- Leading and trailing whitespace
- Values pasted from the clipboard
- Browser autofill using the cc-exp autocomplete token
- Server clock and time zone differences between the client and the API
Common failures
Most defects come from four places. Client-side checks run but the server never repeats them, so a crafted request reaches the gateway. Date parsing treats the current month as expired, which rejects valid cards. The format sent to the gateway differs from the documented one, which returns a generic decline. Validation trims nothing, so a trailing space from a paste fails a value that looks correct on screen.
Automating the check
Run the input cases in your test runner against a mocked gateway, then assert on the field state and the error text. Keep one integration test that hits sandbox mode and inspects the real request payload. Add the suite to your CI pipeline so a change to the checkout form fails the build before it reaches production.