Card Test Cases Study: QA Matrices and Fraud Traffic Patterns

A card test case study examines the set of scripted card transactions used to check how a payment system handles valid, invalid, and blocked cards. The phrase also covers research into card testing fraud, where someone sends many small charges to find out which card numbers are live. Both uses rest on the same question: what should a card attempt look like in the logs when it is legitimate, and what does it look like when it is not.

Card Test Specifications Guide

What are card test cases in payment QA?

A card test case is one scripted attempt with a known expected result: approve, decline, or challenge. QA teams run them against sandbox endpoints before a checkout change reaches live traffic. Each case names the card number, expiry, CVV, amount, currency, and the response code the processor should return.

Card Test Checklists: What to Verify Before You Ship a Payment Flow

Processor test numbers vs. live card data

Most major processors publish test PANs that route to a sandbox. Stripe, Adyen, and Braintree each document numbers that trigger approvals, specific decline codes, and 3D Secure challenges. Some of these numbers pass the Luhn check and some fail it, which makes them useful for testing the validation layer on its own.

card test checklists

• 4242424242424242: passes Luhn, approves in most sandboxes.
• 4000000000000002: passes Luhn, returns a generic decline.
• 4000000000009995: returns an insufficient funds code.
• A number with a bad check digit: fails client-side validation before it reaches the gateway.

What a basic card test matrix includes

• Approved authorization with matching AVS and CVV results.
• Decline for insufficient funds.
• Decline for a stolen card or pick-up card code.
• Expired card date, one month in the past.
• CVV mismatch against an otherwise valid PAN.
• 3D Secure challenge, both passed and abandoned.
• Amount edges: zero-value auth, high-value auth, currency mismatch.

What do studies on card testing fraud find?

Fraud research reads authorization traffic rather than single cards. The pattern is a burst of attempts across many BINs or one BIN range, each with a small amount, sent from rotating IPs. Because the point of the run is to find a card that still works, the useful signal is the ratio of approvals to attempts, not any single transaction.

Traffic patterns in published analyses

• Authorization amounts of $0 to $1, repeated on the same merchant account.
• Hundreds of attempts in minutes, a pause, then a second wave.
• Card numbers that step through a BIN range instead of arriving at random.
• Heavy declines early in the burst, with approvals grouped near the end.
• Device fingerprints and IP addresses that change with each attempt.

How issuers respond

Issuers see card testing as a burst against a single BIN or a narrow range. Many respond by declining all traffic in that range for a short window, which stops the test but also blocks genuine cardholders. That trade-off is why most fraud teams lean on merchant-side velocity rules instead of blanket BIN blocks.

What merchants see after a test run

Card testing leaves a bill the merchant pays: authorization fees on every attempt, chargebacks when stolen cards are used later, and scheme fines when the fraud-to-sales ratio passes a threshold. Visa and Mastercard both run monitoring programs that flag accounts with abnormal authorization patterns. The cost lands on the merchant account, not on the person running the test.

How do you build a card test case set for a study?

1. Define the question. Decide whether you are testing checkout behavior or measuring fraud traffic. The two need different data.
2. Pick a sandbox. Use the processor's documented test PANs so results are reproducible and no live card data enters the dataset.
3. Cover the response space. Include approvals, soft declines, hard declines, 3DS challenges, and validation failures.
4. Log the full response. Store the response code, AVS and CVV result, amount, currency, and timestamp.
5. Run each case twice. A case that passes once and fails on a repeat points to state handling, not card logic.
6. Compare against live aggregates. If the study includes real traffic, use merchant-level counts and never individual card numbers.

Where card test case studies go wrong

• Treating every decline as one result. Issuer codes differ, and a hard decline should not share a bucket with a soft one.
• Skipping the 3DS branch. Authentication outcomes change the authorization result in markets with strong customer authentication rules.
• Using live card data in a test environment. That widens PCI DSS scope and creates a storage problem.
• Ignoring timing. A case that passes at 200 ms can fail under a 100 ms timeout.

FAQ

Are published test card numbers safe to use?

Yes. Numbers that processors publish for sandbox use are not tied to real accounts and cannot be charged. Use them in test mode only, and never mix them with live keys.

How long does a card testing burst last?

Public incident reports describe runs from a few minutes to several hours, often split into waves to stay under velocity limits. Duration alone is a weak signal; amount and decline ratio matter more.

Do card test cases need a real CVV?

No. Sandbox test cards accept any CVV, and some processors list fixed CVV values for specific scenarios. Real CVV values should never appear in a test dataset.