Card Test Cases: Payment Flow Testing Guide

What card test cases are

Card test cases are the scripted checks a QA engineer runs against a checkout or billing form using sandbox card numbers and simulated outcomes. They answer one question: does the payment flow behave per spec when a card is accepted, declined, challenged, or malformed? Providers publish test card numbers that map to specific results, so you never touch a live account balance to exercise a decline.

Prerequisites

• Sandbox merchant account with test API keys
• Test card list from your payment provider, including decline and 3DS triggers
• Staging build with logging on the payment endpoint
• Written rule that only sandbox PANs enter the test suite

Core card test cases

1. Submit a sandbox card with a valid expiry and CVC, then confirm the order reaches the authorized state.
2. Submit an expired sandbox card, then confirm the decline message shows and no order record is created.
3. Enter a digit string that fails the Luhn check, then confirm the form blocks submission before any API call.
4. Pair a valid card number with a wrong CVC, then confirm the issuer response maps to a generic customer message.
5. Trigger the insufficient funds test card, then confirm the retry prompt appears and the cart stays intact.
6. Trigger the 3DS challenge card, then confirm the redirect, the return URL, and the final order state.
7. Leave a required field blank, then confirm inline validation fires on blur and on submit.
8. Double-click the Pay button, then confirm idempotency keys stop a second charge.
9. Cut the network during authorization, then confirm the order lands in a pending state with no duplicate charge.
10. Repeat the same decline three times, then confirm the retry counter locks the form per your risk policy.
11. Run a full refund against a captured test transaction, then confirm the ledger and the customer record match.

Edge cases worth adding

Malformed input breaks more checkouts than declined cards. Add cases for card numbers with spaces, dashes, or trailing whitespace, for numbers shorter and longer than the expected length, for pasted values with hidden characters, and for non-ASCII text in the name field. Test address verification with a mismatched postal code. Test a currency that the merchant account does not support. Test a zero-dollar authorization if your flow uses one.

Evidence to capture

Log the request ID, the response code, the order state before and after, and a timestamp for each run. Store the sanitized payload, never the full card number. A test case without captured evidence cannot be re-run when a release fails.