A card test case is a written check that verifies how software reads, validates, and stores payment card data. It defines the input (a card number, expiry, CVV, or postal code), the steps to run, and the expected result. QA teams run these cases against sandbox card numbers before any live traffic reaches a payment gateway.
Strong card test cases cover three layers: format validation, gateway response handling, and data storage rules. A case that passes in the browser but fails at the gateway is still a bug.
What does a card test case check?
Most card test cases target the same handful of behaviors. Each one maps to a failure you can observe in production.
- Length and character rules: PANs run 13 to 19 digits under ISO/IEC 7812.
- Luhn checksum: the mod-10 check that catches most typos.
- Issuer range (IIN or BIN): the first six to eight digits decide card brand and routing.
- Expiry logic: past dates, the current month, far-future dates, and two-digit against four-digit years.
- CVV format: 3 digits for Visa, Mastercard, and Discover; 4 for American Express.
- Decline paths: insufficient funds, expired card, do-not-honor, and failed 3DS challenges.
- Storage and logging: the CVV must never reach a log file, database row, or analytics event.
Where do test card numbers come from?
Every major processor publishes sandbox card numbers that trigger fixed outcomes. Stripe, Adyen, Braintree, PayPal, and Authorize.Net all ship test cards tied to specific approval and decline codes.
These numbers exist for testing. They carry no funds, belong to nobody, and work only in sandbox mode. A card number scraped from a forum or sold as "guaranteed valid" is a different object, and running one against a live gateway is access device fraud under 18 U.S.C. § 1029.
Common sandbox numbers
- Visa approval: 4242 4242 4242 4242
- Mastercard approval: 5555 5555 5555 4444
- American Express approval: 3782 822463 10005
- Declined card: 4000 0000 0000 0002
Sandbox lists change between processors and over time. Pull the current set from your gateway's own documentation rather than a blog post from 2019.
How do you write a card test case step by step?
- Name the case after the behavior under test, for example "Expired card returns decline code 54".
- Set preconditions: environment, user state, cart total, and currency.
- List exact input values, including PAN, expiry, CVV, and billing ZIP.
- Write the numbered steps a tester follows.
- State the expected result in one sentence a machine could grade.
- Record the actual result and attach the gateway response payload.
Keep one assertion per case. A case that checks both Luhn rejection and decline mapping fails in different ways across releases, and you lose the signal.
Luhn algorithm test cases
The Luhn check (ISO/IEC 7812, Annex B) is a checksum computed over the digits of a card number. Double every second digit from the right, subtract 9 from any result above 9, sum the digits, and the total must divide by 10.
Test both directions. A valid number with one digit changed should be rejected by the client before any network call. A number that passes Luhn but fails at the gateway should return a clean error, not a crash.
Edge cases worth a case each
- All zeros.
- Minimum length (13 digits) and maximum length (19 digits).
- Leading and trailing spaces, plus spaces every four digits.
- Letters and symbols typed into the number field.
- A Luhn-valid number with an unknown issuer range.
Negative and security test cases
Negative cases catch the bugs that cost money. Add one case for each decline code your gateway returns, plus cases for timeouts and repeat submissions.
- Double-clicking Pay creates one charge, not two (idempotency key check).
- A gateway timeout leaves the order pending, never marked paid.
- The CVV field is masked in the UI and absent from every log.
- The full PAN never appears in application logs, stack traces, or analytics.
- Card data is not written to local storage or cookies.
- Abandoning a 3DS challenge returns the shopper to checkout with the cart intact.
PCI DSS rules for card testing
PCI DSS Requirement 3 forbids storing sensitive authentication data (the CVV, full track data, and PIN block) after authorization, in any environment. Requirement 4 covers encryption of cardholder data in transit.
Use tokenized or processor-hosted fields so your test environment never holds a PAN. If your sandbox sits in scope, keep it segmented and documented. Scoping questions belong with your acquirer or a QSA, not a checklist you found online.
Common mistakes in card test cases
Most failures trace back to a short, optimistic test set.
- Testing the happy path with one Visa number and calling it done.
- Hardcoding a sandbox PAN in a shared fixture file that later points at production keys.
- Asserting on UI text instead of the gateway response code.
- Skipping the CVV storage check because "it is just a test environment".
- No case for partial refunds or voided authorizations.
- No case for a card that passes client checks but fails issuer authentication.
FAQ
What is a card test case?
A card test case is a documented input-and-expected-result pair that checks payment card handling, from format validation through gateway response and storage. It lives in your test management tool next to any other functional case.
Are test card numbers real?
No. Sandbox numbers from processors such as Stripe or Adyen are published placeholders that route to simulated responses. They hold no funds and cannot complete a real purchase.
Can I store a CVV in a test environment?
Not if the environment touches real cardholder data. Under PCI DSS Requirement 3.2, sensitive authentication data cannot be stored after authorization. Use processor tokens and synthetic values instead.
How many card test cases does a checkout need?
Aim for coverage of each brand you accept, each decline path you display, and each storage rule you must prove. A small shop lands around 25 to 40 cases once negative, idempotency, and timeout checks are counted.
Start with one case per brand, add one per decline code, then close the gaps your first release exposes. The suite grows from real bugs, not from a template.