What is a card test case?
A card test case is a documented scenario that verifies how a payment system responds to one specific card input, such as an approved charge, a declined authorization, an expired card, or a CVV mismatch. Each case records the card data used, the steps taken, and the expected result so any tester can repeat it and see the same outcome.
Sound card test cases use sandbox card numbers and accounts you control. They never rely on card data that belongs to someone else.
Why do card test cases matter in payment QA?
Payment failures cost revenue and trust, and most defects hide in edge cases rather than the happy path. A structured card test case set finds validation gaps before real customers hit them.
Coverage also supports compliance. Auditors want evidence that cardholder data stays protected in test environments, a requirement PCI DSS spells out.
Which scenarios should every card test case suite cover?
- Approved purchase with a valid sandbox card and matching CVV
- Decline codes: insufficient funds, stolen card, do not honor, expired card
- CVV mismatch and postal code (AVS) mismatch
- Expired cards and cards with a bad Luhn check digit
- 3D Secure challenge, success, and abandonment
- Refunds, partial refunds, voids, and chargebacks
- Duplicate submissions and idempotency keys
- Currency, country, and card brand variations
- Network timeouts and gateway retries
What is the difference between a positive and a negative card test case?
A positive card test case confirms the system completes a valid transaction and records it in the right ledger. A negative card test case confirms the system rejects bad input with the correct error code and leaves no partial charge behind.
Both belong in the same suite. Teams that test only happy paths ship bugs in decline handling, which is where most support tickets begin.
What fields belong in a card test case template?
- Case ID and short title
- Objective in one sentence
- Preconditions: environment, merchant account, currency
- Test data: card number source, expiry, CVV, amount
- Numbered steps
- Expected response code and expected account state
- Actual result, status, and tester name
How do you write a card test case step by step?
- State the objective in one line, such as verify decline for an expired card.
- List preconditions: sandbox endpoint, merchant ID, currency, and card source.
- Write numbered steps with the exact card number, expiry, CVV, and amount.
- Record the expected authorization code and the expected ledger entry.
- Log the actual result and a pass or fail verdict after each run.
Keep one behavior per case. When a single case covers three rules at once, a failure tells you nothing about which rule broke.
What are common mistakes in card testing?
Reusing one test card for every scenario hides brand specific behavior. Skipping idempotency checks lets duplicate charges reach production. Storing live card data in a test database breaks PCI DSS and creates real liability.
Another frequent gap is missing cleanup. Test transactions that stay in reporting skew settlement totals and confuse finance teams.
Is it legal to test cards you do not own?
No. Trying card numbers you do not own or control is unauthorized access and carding, and it is a crime in the United States and most other jurisdictions. Valid card testing uses sandbox credentials from your payment processor or your own live card through your own merchant account.
Where do test card numbers come from?
Payment processors and card networks publish documented sandbox numbers for each brand and each decline code. Stripe, PayPal, and Adyen all maintain public test card tables you can copy into your suite.
Card numbering itself follows ISO/IEC 7812, which defines the issuer identification number and the Luhn check digit. That standard is why a mistyped digit fails validation before a request ever reaches an issuer.