Card test cases are scripted checks that confirm a payment form or checkout flow handles card data correctly, from a clean approval through to a hard decline. A complete set covers number, expiry and CVV validation, error messaging, gateway responses, and authentication steps, and it runs against sandbox test cards rather than real card numbers.
What a solid set of card test cases covers
Think of the work in layers. Each layer fails in a different way, so each needs its own cases.
- Field validation: length limits, allowed characters, Luhn checksum, expiry formatting, CVV digit count.
- Gateway responses: approved, soft decline, hard decline, timeout, duplicate submission.
- Authentication: 3-D Secure challenge pass, challenge fail, and abandoned challenge.
- Data handling: tokenization, masking rules, and what the app stores after the charge completes.
- UI behavior: button states, spinners, retry paths, and what the customer sees after each outcome.
Always test against sandbox cards
Every major processor publishes test card numbers for its sandbox, including numbers that trigger specific decline codes and specific 3-D Secure outcomes. Use those numbers only. Real card data in a test environment expands your PCI DSS scope and creates a record-keeping problem you cannot undo, so production numbers should never touch a staging system.
Starter card test cases
- Approved card, valid data. Confirm the order is created, the charge is recorded, and the confirmation screen shows the correct amount.
- Declined card. Confirm the customer sees a readable message, not a raw processor code, and that the order is not fulfilled.
- Expired card. The form should block submission before the request leaves the browser.
- Invalid Luhn checksum. A number that fails the checksum should be rejected client side and again on the server.
- Wrong CVV length. Three digits for most brands, four for American Express.
- Empty required fields. Submit with each field blank in turn and check the error placement.
- Whitespace and dashes in the number. The field should normalize input before validation.
- Expiry in the past, and expiry more than ten years out. Both should be caught.
Validation cases QA teams often miss
Server-side validation deserves its own cases, because browser checks can be bypassed. Send the request directly to the endpoint with a malformed number, a two-digit year, a CVV containing letters, and an overlong cardholder name. The API should reject each one with a clear error and no partial charge. Also test currency and amount edge cases: zero, negative, more decimals than the currency allows, and amounts that cross a rounding boundary.
Decline and error path cases
Declines are the paths customers actually hit, so give them weight. Cover insufficient funds, expired card, incorrect CVV, do-not-honor, and a processor timeout. For each, check that the retry button works, that the cart is preserved, and that a second attempt does not create a duplicate order. Idempotency keys are worth a dedicated case here.
Authentication test cases
If you support 3-D Secure, add cases for a challenge that passes, a challenge that fails, a customer who closes the challenge window, and an issuer that does not participate. Verify how the order state resolves in each branch, since ambiguous states are where fulfilment bugs appear.
Keeping card test cases maintainable
Store test cards in one fixture file rather than scattering them across specs. Name each case after the behavior it proves, not the card number it uses. When a processor changes its sandbox, you update one file instead of forty tests. Review the suite whenever the checkout layout changes, because selector drift is the most common reason a passing suite starts failing for the wrong reason.