A card test case is a defined check that verifies how a payment card behaves in one specific scenario. On a payments engineering team it is a repeatable test run against checkout, gateway, and settlement flows, with an expected response code and an expected ledger effect. In fraud and risk work, the same phrase describes the small, low-value transactions criminals use to learn whether a card number is live. The handling differs by which side of the counter you sit on, so this guide separates the two and gives the checklist for each.

What the term means in each context

Payment QA and engineering

Here a card test case is an artifact: a precondition, a card state, an amount, an entry mode, and an expected outcome. It runs in a sandbox against processor-provided test card numbers. The goal is regression coverage, so a code change to tax, shipping, or retry logic cannot quietly break authorization or refunds.

Fraud and risk

Here a card test case is an attack step. A criminal submits a card number with a small or authorization-only amount, watches the response, and keeps the numbers that approve. At volume this becomes an enumeration attack against a merchant's payment page rather than a single stolen card.

Test cases a payment team should keep

  • Approved authorization with a clean AVS and CVV match
  • Soft decline and hard decline responses, checked by exact code and message
  • Expired card and invalid expiration date
  • CVV mismatch and AVS mismatch, including partial ZIP matches
  • 3D Secure challenge passed, failed, and abandoned
  • Partial refund, full refund, and refund on a settled versus unsettled charge
  • Void before settlement and reversal after settlement
  • Recurring, installment, and stored-credential transactions
  • Duplicate submit and idempotency key reuse on retry
  • Gateway timeout, then a late success webhook
  • Currency conversion and cross-border settlement

What a well-formed card test case contains

  1. Precondition: customer state, cart contents, saved card status
  2. Card under test: sandbox BIN, country, funding type, and expected behavior
  3. Amount and currency, including a boundary value near an auth limit
  4. Entry mode: card on file, keyed entry, wallet, or terminal
  5. Expected response code and customer-facing message
  6. Expected ledger and settlement entries
  7. Cleanup step so the next run starts from a known state

Test data rules that keep you out of trouble

Use sandbox numbers supplied by your processor or acquirer. Never place real cardholder data in a test environment, because test systems sit outside the controls that production PCI scope provides. Keep test card numbers out of production code and configuration, rotate them when a processor retires a range, and log the test run so a reviewer can tell test traffic from live traffic.

How card testing shows up in production

Watch for a cluster of small authorizations across many card numbers from few devices, sequential or near-sequential account numbers, a high ratio of declines followed by a low-value approval, mismatched AVS on card-not-present orders, and a sudden rise in authorization-only traffic that never settles. These patterns describe an attacker probing your gateway using your checkout as the test harness.

Controls that stop a test case from becoming fraud

  • Velocity limits per IP, device fingerprint, email, and card BIN
  • Authorized-only volume monitoring and automatic throttling
  • 3D Secure step-up on risky or new-device traffic
  • Address verification and CVV requirements for keyed entry
  • Bot detection and challenge on the payment page
  • Alerting on decline-then-approve sequences from one source

Which approach fits your role

If you build or maintain a checkout, invest in the QA set first: it protects revenue and it documents expected behavior for support. If you run risk or operations, invest in detection and throttling, because an enumeration run costs you interchange and chargeback fees even when no goods ship. If you are a cardholder, the practical step is a monthly statement review and transaction alerts, since a small test charge is often the first sign of a compromised number.

Scope note

This guide covers how merchants test their own payment flows and how they detect abuse. It does not cover how to test or use card numbers you do not own. That activity, sometimes called carding, is fraud under federal and state law, and card networks and issuers build the detection controls described above specifically to catch it.