What card test cases are

Card test cases are scripted checks for a payment flow. Each case sets a starting state, submits a card value, and asserts the result. A full suite covers approvals, declines, expired cards, bad CVC values, network failures, and retries. The cases run against a payment processor sandbox. The card values come from the processor's published test list. Real card numbers do not belong in a test environment.

Test card numbers come from the processor

Stripe, Adyen, Authorize.net, and Braintree each publish fake PANs that trigger fixed outcomes in their sandbox. Stripe lists these, among others:

  • 4242 4242 4242 4242: Visa, approves.
  • 4000 0000 0000 0002: generic decline.
  • 4000 0000 0000 9995: insufficient funds decline.
  • 4000 0000 0000 0069: expired card decline.
  • 4000 0000 0000 0127: incorrect CVC decline.
  • 4000 0000 0000 3220: requires 3D Secure authentication.

Check the processor reference page before writing cases. Numbers and decline codes change, and each processor maps them to its own error codes.

Core scenario list

  1. Approved card with correct CVC and future expiry.
  2. Generic decline. Assert the error message shown to the buyer.
  3. Insufficient funds decline. Assert a distinct message.
  4. Expired card. Assert client-side validation blocks submit.
  5. Incorrect CVC. Assert the retry path.
  6. 3D Secure challenge, pass and fail branches.
  7. Luhn check failure. Assert no network call fires.
  8. Empty fields and whitespace-only input.
  9. Card number with spaces and dashes. Assert normalization.
  10. Processor timeout. Assert no double charge.
  11. Duplicate submit on a slow connection. Assert idempotency key reuse.
  12. Full refund and partial refund.
  13. Zero-amount authorization, if the processor allows it.
  14. Currency mismatch between cart and processor account.

Fields a test case needs

  • Case ID and short title.
  • Preconditions: cart state, account state, sandbox mode on.
  • Steps in order, one action per step.
  • Test data: PAN, expiry, CVC, amount, currency.
  • Expected result: HTTP status, processor response code, UI state, stored record.
  • Cleanup step.

Data rules

PCI DSS forbids storing sensitive authentication data after authorization. That covers the full PAN, the CVC, and the track data. Test suites that log full card values break this rule even when the values are fake, because the habit carries into production code. Log the last four digits and a token instead. Mask the CVC field in every screenshot and every debug dump.

Automation notes

Write one case per row in a data table. Keep the assertion on the processor response code, not on the message string, since copy changes. Run the decline cases on every build. Run the 3D Secure cases on a schedule, since they need a browser session. Confirm each case fails when you break the code on purpose. A test that passes against a stub returns nothing.

Pass and fail criteria

A case passes when the response code, the stored order record, and the screen state all match the expected values. A case fails when any one of the three drifts. Track the failure rate per scenario so a broken decline path shows up before release.