Card test case buying advice

Do not buy CVV data. For legitimate card test cases, use test card numbers supplied by your payment processor's sandbox environment. Real CVVs are sensitive authentication data. Buying, selling, or using them without authorization is illegal and creates fraud, chargeback, and compliance risk. If your goal is to validate checkout flows, refunds, declines, and 3D Secure behavior, use documented sandbox PANs, future test expiry dates, test CVVs, and processor-defined response codes. Treat any offer to sell real card verification values as a fraud risk, not a testing shortcut.

What to look for in card test cases

• Test card numbers that match the processor's documented sandbox behavior, including approval and decline scenarios.
• Coverage for common decline codes such as insufficient funds, expired card, incorrect CVV, and do not honor.
• Separate test data for card brands, currencies, and countries if your checkout supports them.
• 3D Secure test profiles for challenge, frictionless, and failed authentication flows.
• Clear expected results for each card test case so QA can verify the UI, API response, and order state.
• Environment isolation that prevents sandbox test cases from reaching live payment rails.

Parameter bands for sandbox test cases

Use processor-provided values instead of inventing card data. A typical test card case includes a 16-digit test PAN, a future expiry date, a 3-digit or 4-digit test CVV depending on card brand, a small test amount, and an expected response. Keep test amounts low and fixed so results are repeatable. Include at least one approved case, one CVV mismatch case, one expired-card case, one insufficient-funds case, and one authentication failure case. For API testing, record the request ID, response code, decline reason, and final order status for each card test case.

Pitfalls to avoid

• Using real cardholder data in a test environment.
• Storing CVV values after authorization, even in logs or test fixtures.
• Assuming a random number will behave like a valid test card.
• Testing only successful payments and skipping decline and authentication paths.
• Mixing sandbox and production credentials during card test case runs.

FAQ: Can I use any number as a card test case?

No. Use the test card numbers published by your payment processor. Random numbers may trigger validation errors, rate limits, or fraud controls without testing the behavior you need.

FAQ: Are card test cases legal for QA?

Yes, when you use sandbox test data from your processor and keep real cardholder data out of the test process. Buying or using real CVV data is not a legitimate testing method.

FAQ: What should a card test case record include?

Record the test PAN label, expiry, test CVV, amount, currency, authentication mode, expected response, actual response, and timestamp. This makes payment testing repeatable and auditable.