Card Test Checklists: Payment QA Steps Before Launch

A card test checklist is a fixed list of checks your team runs against a payment flow before release and after every change: approved test card numbers, each decline code the gateway can return, CVV and AVS response handling, 3-D Secure branches, retry rules, and the log records each step leaves behind. Build it once using your processor's sandbox test cards, keep real card numbers out of it, and run the same list on every deploy.

card test checklists

Why a fixed checklist beats ad-hoc testing

Payment bugs hide in branches you forget to open. A tester who clicks through one successful purchase has tested maybe ten percent of the flow.

more on this topic

A written checklist forces the boring cases: expired cards, wrong CVV, mismatched billing address, duplicate submit, timeout on the authorization call. Those are the cases that produce double charges and angry tickets.

Card Test Protocols: A Comprehensive Guide

The list also survives staff turnover. A new QA hire can run it without asking anyone which test card triggers a soft decline.

What belongs on a card test checklist?

Group the items by layer so failures point to a cause. A workable structure:

• Card number rules. Luhn validation, accepted card brands, minimum and maximum length, blocked BINs, spacing and dash handling in the input field.
• Expiry and CVV fields. Past dates rejected, month/year edge cases, three-digit and four-digit CVV lengths, empty field behavior.
• Authorization outcomes. Approval, soft decline, hard decline, call-for-issuer, pickup, and any custom codes your processor documents.
• AVS and CVV response mapping. Each combination of address result and security code result mapped to the right order state.
• 3-D Secure paths. Frictionless pass, challenge pass, challenge fail, challenge abandoned, timeout.
• Retries and idempotency. Repeat submit blocked, network timeout handled once, no duplicate charge on refresh.
• State changes. Order, invoice, email, and webhook all updated in step with the gateway response.
• Logging and data storage. CVV never written to disk or logs, PAN masked, request IDs captured for support.

Which test cards and scenarios should you use?

Use only the sandbox test cards published by your payment processor. Stripe, Adyen, Braintree, and most gateways publish a set of numbers that trigger specific responses, and those numbers behave the same way every run.

Map each checklist item to one test card. If your processor lists a number for "insufficient funds" and another for "incorrect CVV," write both into the checklist next to the expected result.

Test in the sandbox first, then repeat a short smoke subset in production with a real card you own and a refund back to it. Live card numbers that belong to other people have no place in a QA environment.

How do you test CVV and AVS handling without real card data?

Processors expose simulated address and security code outcomes in the sandbox, usually triggered by the amount, the postal code you submit, or a specific test number.

Write a small matrix: CVV match plus AVS match, CVV match plus AVS mismatch, CVV fail plus AVS match, both fail. Confirm the order state, the customer message, and the fraud rules each combination produces.

What does a good payment regression checklist include before launch?

1. Run every item on the core checklist against the release candidate.
2. Confirm the decline message a customer sees matches the actual reason, or is vague enough to avoid leaking data.
3. Check that a failed authorization leaves no pending order and no orphaned inventory hold.
4. Verify webhooks arrive and are idempotent when the same event fires twice.
5. Read the logs from one failed and one successful run and confirm no CVV or full card number appears.
6. Test the refund and void paths, not just the sale path.

How do you tell a QA test from a card-testing attack?

Card testing attacks look like your own QA traffic at first: many small authorization attempts, rapid repeats, and a spread of card numbers across one IP or device. The difference is ownership. Your testers use sandbox credentials or their own cards, and the volume is small and scheduled.

Add a monitor to your checklist so you can spot the pattern: count failed authorizations per IP per hour, flag more than a handful of BIN variations from one session, and alert on attempts under a dollar. Then make sure your gateway's own fraud rules and any rate limits actually fire when the pattern appears.

Should the checklist live in the repo or a spreadsheet?

Put it in the repo next to the payment code, one markdown file per flow, with the test card next to each expected result. Review it whenever the gateway contract changes.

A spreadsheet works for a small team, but it drifts. Version control keeps the checklist honest about what the current build should do.

Common gaps that show up in review

• No test for the browser back button after a completed payment.
• Decline messaging that differs between the checkout page and the confirmation email.
• Missing checks on the CVV field after a card is saved to a wallet.
• Retry logic that fires on hard declines, which should never be retried.
• No documented expected result, so a tester cannot tell a pass from a fail.

A checklist item without an expected result is a note, not a test. Fix that before you add more items.