A card test case is a documented check with a defined input, a set of steps, and an expected result that verifies how a payment form or API handles a card number, expiry date, and CVV. QA teams run these cases in a sandbox using processor-issued test card numbers, never live cardholder data.
What does a card test case contain?
Every case needs five fields: the input data, the environment, the steps to run, the expected response, and the pass criteria. The expected response should name the exact status code or on-screen message, not a vague note that it works.
- Card number, expiry, and CVV used as input
- Endpoint or screen under test
- Expected authorization result: approve, decline, or error
- Expected validation message for malformed input
- Cleanup step so the case can rerun in isolation
Which test card numbers belong in a card test suite?
Processors publish fixed numbers that trigger specific responses in a sandbox. Stripe documents 4242424242424242 for a successful Visa charge and 4000000000000002 for a generic decline, which covers the two outcomes most suites need first.
- 4111111111111111: Visa, passes the Luhn check
- 4242424242424242: Visa, approved in sandbox
- 5555555555554444: Mastercard, approved in sandbox
- 4000000000000002: card declined
- 4000000000009995: insufficient funds
How do you test card number validation?
Card numbers must pass the Luhn checksum before any network call, so build cases that isolate that rule. Change a single digit and confirm the form rejects the number locally without contacting the processor.
Then test length and prefix rules per brand: 16 digits for Visa starting with 4, and 16 digits for Mastercard starting with 51 through 55 or 2221 through 2720. A 15-digit American Express number starting with 34 or 37 exercises a different branch of the validator.
How do you test CVV and expiry validation?
CVV cases should cover 3 digits for Visa and Mastercard, 4 digits for American Express, and a leading-zero value such as 0123. Add an empty field, a 2-digit value, and a 5-digit value to confirm each message names the real problem.
Expiry cases should include a past month, the current month, a date far in the future, month 13, and a two-digit year that must map to a four-digit year. February in a leap year is a useful edge case for the date parser.
What negative card test cases get skipped?
- Spaces and dashes typed or pasted inside the card number
- Non-numeric characters pasted into the field
- Resubmitting the same request to confirm idempotency
- Timeout and retry behavior on a slow processor response
- Declines that must not create an order or charge record
How do you handle 3-D Secure and tokenization cases?
Sandbox environments ship authentication triggers for 3DS, so add cases for challenge passed, challenge failed, and challenge abandoned by the shopper. Tokenization cases should confirm the raw card number never comes back from the API and that a stored token charges the correct amount exactly once.
How do you keep card test data compliant?
PCI DSS requires that production cardholder data never reaches test or development systems, which is the reason sandbox card numbers exist. Keep the numbers in a shared fixture file, label them as fake, and rotate any credential that appears in logs.