What are card test cases?

Card test cases are written checks that confirm a payment system handles card data the way the spec says it should. Each case pairs a set of inputs (card number, expiry, CVV, billing ZIP) with an expected outcome such as an approval, a decline, or a validation error. QA teams run them in a processor sandbox before the code reaches production.

The suite covers two layers. The first layer is validation: length, character set, Luhn checksum, and expiry dates. The second layer is the gateway response: approvals, declines, 3-D Secure challenges, timeouts, and duplicate submissions.

Which test card numbers should you use?

Use the sandbox numbers your processor publishes. These cards work against test endpoints and carry no real account behind them.

  • 4242 4242 4242 4242: Visa, approval.
  • 4000 0000 0000 0002: Visa, generic decline.
  • 4000 0000 0000 3220: Visa, requires 3-D Secure authentication.
  • 5555 5555 5555 4444: Mastercard, approval.
  • 3782 822463 10005: American Express, approval (15 digits, 4-digit CID).

Payment providers publish lists in this same format and document which number triggers which response code. Pull the numbers from your own processor's docs, because decline triggers differ between vendors and change over time.

How do you write a single card test case?

Use a fixed structure so results stay comparable across runs and across testers.

  1. Case ID and title, such as "PAY-014: Visa approval with valid CVV".
  2. Preconditions: sandbox account, test card list loaded, 3-D Secure toggled off.
  3. Steps: numbered actions a tester follows in the UI or the API call.
  4. Test data: card number, expiry, CVV, amount, currency.
  5. Expected result: the exact status, message, and database state.
  6. Actual result and pass/fail, logged with build number and timestamp.

Write the expected result as an assertion, not a description. "Order status moves to paid and a token is stored" beats "payment should work".

Which validation scenarios matter most?

Input validation catches most bugs before the gateway is called. Test the boundaries on both sides of every rule.

  • Luhn check: a number that fails the checksum gets rejected before the request leaves your server.
  • Length: too short, exact minimum, exact maximum, one digit over.
  • Formatting: spaces, dashes, leading zeros, mixed case for the Amex CID.
  • Characters: letters, symbols, SQL fragments, non-ASCII digits.
  • Expiry: last month, current month, next month, year 2099, year 1999.
  • CVV: 3 digits for Visa and Mastercard, 4 for Amex, empty, 5 digits, letters.
  • Empty and whitespace-only fields, plus paste and browser autofill behavior.

Run each case at the API layer as well as the UI. Client-side rules are trivial to bypass, so the server has to repeat every check.

What do you test on the decline path?

Declines are where payment code breaks in production. Force each response and confirm the UI, the order record, and the retry logic all behave.

  • Insufficient funds, expired card, stolen card, do not honor.
  • CVV mismatch and address verification (AVS) mismatch responses.
  • 3-D Secure challenge, failed challenge, abandoned challenge.
  • Gateway timeout and connection reset after the request was sent.
  • Duplicate submit: the same idempotency key twice returns one charge, not two.
  • Amount edge cases: zero, minimum allowed, over the processor limit.

A decline must never leave the order in a paid state. Check the database, not just the screen.

How do you test stored cards and tokens?

Tokenization cases verify that raw card numbers never reach your servers or your logs. Confirm the token survives a page reload, that a deleted card cannot be charged, and that one customer's token cannot pay for another customer's order. Then search your logs and error reports for the card number pattern. A single hit is a failed case.

Why should you never test with real card data?

Storing a real card number without PCI DSS controls invites a breach and violates card network rules. Testing a card you do not own, or checking whether someone else's card is live, is carding and carries criminal liability in the US and most other countries. Sandbox numbers, tokens, and processor test accounts give you full coverage with no risk.

What does a solid card test suite cover?

  • One case per validation rule, boundaries included.
  • One approval case per card brand you accept.
  • One decline case per response code the gateway can send.
  • One case per 3-D Secure outcome.
  • Token, refund, partial refund, void, and chargeback flows.
  • A regression run on every release and a smoke test on every deploy.

Keep the suite in version control next to the code. Payment bugs cost real money, and a case you cannot rerun is a case that will fail again.