Answer
A card expiry test checks the expiry field on a payment form. It confirms the form accepts a four digit MM/YY value in the future and rejects dates in the past, month values above 12, and malformed input. It does not confirm that the card exists, that the account is open, or that the CVV matches. Those checks run at the issuer during authorization.
What "v5" means
"Card expiry test v5" is a version label used by test suites and QA teams. No standards body defines v5. Two vendors can ship the same label with different case sets. Treat the number as a build tag for one set of cases, not as a shared specification.
Expiry date format
Payment forms collect the expiry as two digits for the month and two digits for the year: 09/28. ISO/IEC 7813 defines the field on magnetic stripe track data as YYMM, so the month comes last there. Cards print MM/YY. Processors publish both layouts in their APIs, so a suite has to cover the conversion.
Cases a suite should cover
- Valid month and valid future year: 01/30
- Single digit month with no leading zero: 1/30
- Month 00 and month 13
- Expiry in the current month, which issuers accept until the last day
- Expiry in the prior month
- Two digit year that maps to a past decade, such as 99
- Four digit year entry: 2030
- Spaces, slashes, dots, and pasted input such as 09 2028
What expiry validation does not do
The Luhn check digit covers the card number. The expiry field has no check digit. Any MM/YY pair that passes the format rules is valid input. A form that accepts 4242 4242 4242 4242 with 01/30 is working as designed in a sandbox. Stripe and other processors publish sandbox card numbers that pass with any future expiry date and any three digit CVC.
PCI DSS context
PCI DSS forbids storage of sensitive authentication data after authorization. The CVV sits in that category. Requirement numbering differs between PCI DSS v3.2.1 and v4.0, and the prohibition holds in both. A suite that writes a CVV to a database or a log file fails the control. Test environments use sandbox values, never live card data.
Reporting
A useful run reports each case as pass or fail, the input string, the field state, and the response code from the tokenization call. Screenshots do not survive review. Store the case ID and the request body with the card number masked.