Card test cases are scripted checks that verify how a checkout form validates, formats, and processes payment card data. A complete set covers card number rules, expiration dates, security codes, cardholder names, processor declines, and the error messages a shopper sees. Each case records preconditions, input, expected result, and the environment, which should be a processor sandbox rather than a live account.
What should every card test case include?
A card test case needs four parts: setup, input, action, and expected outcome. Without an expected outcome tied to a specific processor response, the case cannot pass or fail.
- Preconditions, such as an empty cart or a signed-in user
- Exact input values and the card brand they represent
- The expected validation, network, and interface response
- Cleanup steps so the next case starts from the same state
Which card test cases are mandatory?
Start with field-level cases, then move to integration cases. Field validation catches most defects before any network call happens.
- Valid card number in each accepted brand
- Number with an incorrect Luhn checksum
- Number that is too short or too long
- Past expiration date and current-month expiration date
- Security code with too few digits for the brand
- Empty required fields and whitespace-only input
- Approved, declined, and expired-card sandbox responses
- Duplicate submit, double click, and page refresh mid-payment
- Locale and timezone differences in date entry
How do you test card number validation?
The card number field carries the most risk, so it deserves the most cases. Check length rules per brand, checksum failure, spaces, dashes, and pasted strings that mix separators.
Payment processors publish sandbox test numbers that pass the Luhn algorithm and return fixed results. Those numbers let you test approval and decline paths without touching real card data.
Should you ever test with a real card?
No. Live card data belongs in production only and pulls the test environment into PCI scope. Use processor-provided test numbers and keep card data out of logs, screenshots, and bug reports.
How do you write a clear card test case?
- Name the case after the rule it checks, such as "expired card shows inline error".
- State the precondition and the exact input value.
- Describe the expected field message, network call, and final order state.
- Note the browser, device, and sandbox response code used.
- Add the case to a regression suite that runs before every release.
What mistakes weaken card test suites?
Most weak suites test only the happy path and only one card brand. Others hard-code a single sandbox response and never check decline handling.
Another common gap is testing validation without testing accessibility, so error messages never reach screen reader users. Pair each functional case with a keyboard and assistive-technology check.