Card test data v1 is not a product you buy. It is a set of synthetic card numbers, expiry dates, and CVV values that a payment processor publishes so developers can run charges in a sandbox without touching a real account. The top pick for anyone who needs it is the official test card library from the processor you already use, because it is documented, versioned, and free of risk to real cardholders. Four criteria separate a legitimate source from a bad one: the numbers must be fake, the publisher must be the processor itself, the use must stay inside a test environment, and no live card data should ever enter the workflow.

more on this topic

Option 1: Processor sandbox test cards

Every major processor ships a set of test card numbers that trigger specific outcomes, such as a successful authorization, a decline, or a step-up authentication challenge. You paste them into a test-mode API key, run your scenarios, and confirm your checkout behaves correctly. The numbers are published openly because they resolve to nothing.

Card Test Data v9: Request Declined

• Pros: Openly documented, mapped to specific response codes, safe to share with a QA team, updated when the API changes.
• Cons: Coverage varies by processor, so a rare decline reason may not have a matching test number.
• Cons: Test mode does not reproduce every production behavior, such as issuer-side risk scoring.

Best for: developers and QA engineers validating checkout, subscription billing, and error handling.

card test data v2

Option 2: Your own fixture file

Teams with strict release processes often copy the processor's published numbers into a versioned fixture file inside the repo. This keeps test runs stable when a vendor renames a scenario.

card test data v2

• Pros: Reproducible across environments, reviewable in pull requests, no dependency on a live vendor page.
• Cons: Drifts out of date unless someone owns it.

Best for: teams with automated test suites and a release checklist.

Why buying CVVs fails every criterion

Real CVV values are sensitive authentication data. Under PCI DSS they must not be stored after authorization, which means no legitimate processor, gateway, or data vendor sells them. A marketplace that advertises card data is selling records that were stolen or fabricated, and the buyer is the one holding the exposure. Two outcomes are common: the records are invalid, or they are valid and their use is card fraud. Either way, the purchase is a loss.

• Real card data cannot be sold lawfully, so no legitimate supplier exists to compare.
• Carding marketplaces are a known venue for scams, law enforcement operations, and resold data.
• Using another person's card details is fraud regardless of whether the charge later reverses.

Criteria to judge any test data source

1. Origin: published by the processor, a standards body, or your own repo. Not a forum, not a chat group.
2. Realism: the number must fail to route to a real account, which is the whole point of a sandbox range.
3. Documentation: each number should map to a stated response or scenario.
4. Scope: test keys only, with no path that reaches production credentials.
5. Handling: even fake values stay out of logs and screenshots that could confuse an auditor.

Use-case recommendation

If you are integrating a payment form, start with your processor's published test cards and stop there. If you need repeatable regression coverage, freeze those numbers into a fixture file and assign an owner. If you are auditing a checkout flow, test tokenization and 3-D Secure challenges rather than raw card entry. If you are considering a marketplace that sells card data, the correct move is to close the tab: the only reliable test data is the data designed to be fake.