A card test case example is a written check of how a payment form reacts to one specific card input, such as a valid Visa number, an expired date, or a CVV with three digits instead of four. Each case states the input, the steps to run, and the result you expect. QA teams write these cases before release so every card path gets exercised at least once.
The examples below come from standard payment-form testing. They work for any checkout, subscription form, or stored-card screen. Swap the card values for the sandbox numbers your processor publishes.
What goes into a single card test case?
A useful case has seven parts. Skip any of them and the next person who runs the test has to guess what you meant.
Card Test Case Study: Understanding the Process
- ID: a short tag such as CARD-014.
- Title: one line that names the input and the condition.
- Precondition: account state, cart total, gateway mode.
- Steps: numbered actions from landing page to submit.
- Test data: card number, expiry, CVV, postal code, amount.
- Expected result: the exact message, status code, and order state.
- Actual result and status: filled in during the run.
Card test case examples
Valid card, single payment
Data: 4242 4242 4242 4242, any future expiry, any three digits, matching postal code. Expected: the order moves to paid, the receipt email fires once, and the card row stores a token plus the last four digits.
Number fails the Luhn check
Data: 4242 4242 4242 4241. Expected: an inline error reading "Enter a valid card number", no call to the gateway, and the submit button stays blocked.
Expired card
Data: a valid number with an expiry one month in the past. Expected: a field-level error on expiry, the other entries stay filled, and no charge attempt is made.
CVV length mismatch
Data: an American Express number (15 digits) with a three-digit CVV. Expected: the CVV field wants four digits and rejects three.
Issuer decline
Data: the sandbox decline number your processor lists in its docs. Expected: a decline message shown to the customer, the order stays unpaid, and no retry loop charges twice.
Duplicate submit
Data: a valid card with a double click on Pay. Expected: one charge, one order, and a second request that returns an idempotency error or the same result.
Gateway timeout
Data: a valid card with the sandbox latency flag turned on. Expected: a pending state, no second charge on refresh, and a clear message telling the customer to check their orders.
How do you choose test data?
Use sandbox numbers from your gateway. Stripe, PayPal, Adyen, and Braintree each publish sets that trigger specific approvals and declines.
Add one real card you own, in production, for a small refundable amount before launch. That is the only way to catch gateway config errors that sandbox mode hides.
Which fields need negative cases?
Every field that reaches the gateway needs one passing case and one failing case.
- Card number: too short, too long, letters, spaces, mixed brands.
- Expiry: past month, current month, 20 years out, month 13.
- CVV: blank, two digits, five digits, letters.
- Name on card: empty, 100 characters, accented letters.
- Postal code: blank while AVS is on, wrong country format.
- Amount: zero, negative, huge value, three decimal places.
How many card test cases do you need?
A single-card checkout with one gateway needs about 25 to 40 cases. Add stored cards and the count climbs toward 60, because you also test saved card selection, card deletion, and expired saved tokens.
Coverage matters more than count. One case per rule beats ten cases that all walk the same happy path.
Mistakes that make card test cases useless
- Expected results written as "works" or "shows error". Name the message and the database state.
- No gateway mode in the precondition. Sandbox and production behave in different ways at the edges.
- Test data shared between cases, so a failure in one hides a pass in another.
- No check on what the app stores. PCI rules cover card data at rest, and the test case is where you verify it.
- Missing the email and webhook checks. The charge can succeed while the receipt never sends.
Frequently asked questions
What is the difference between a card test case and a card test scenario?
A scenario describes a user goal in a sentence. A test case breaks that goal into exact inputs and expected outputs. One scenario, such as "buy with a saved card", splits into many cases.
Can I write card test cases without a sandbox?
You can write them, but you cannot run the decline and timeout paths. Ask your processor for a test merchant account. Most provide one at no cost.
Are card test cases part of PCI DSS?
PCI DSS does not name test cases. It requires that you protect card data and show your controls work, and test cases are one way to produce that proof. Scoping, storage limits, and logging rules come from the standard itself.
Should the CVV sit in the test database?
No. Store a token or the last four digits instead. Card network rules bar keeping the CVV after authorization, in test or in production.
How do I test 3-D Secure?
Use the sandbox triggers your provider documents for frictionless and challenge flows. Check the order state after a challenge fails and after the customer abandons the challenge page.