Card test data is a set of fake card numbers, expiry dates, and CVV values that developers use to exercise a payment flow without touching a real cardholder account. Payment processors issue it for sandbox and staging environments only, and a live gateway will always decline it. Good card test data lets you verify approvals, declines, 3-D Secure prompts, and error handling before a single real transaction runs.

Card Test Data V10: Guide on Where to Buy CVV

What counts as card test data

Test data mimics the shape of a real payment request without carrying any value. A complete test record usually includes a card number that passes the Luhn check, a future expiry date, a CVV, and sometimes a cardholder name and billing ZIP that match the scenario you want to trigger.

more on this topic

• Test PANs are non-issued numbers reserved by the processor for testing. They look valid to your form validation but belong to no one.
• Scenario triggers are specific numbers that force a decline, a processing error, or a fraud rule hit so you can test unhappy paths.
• 3-D Secure test cards simulate the challenge flow, including successful authentication and abandonment.
• Tokens and mock objects replace a card number after tokenization, letting you test repeat charges without reusing raw data.

Where card test data comes from

Processors and gateways publish their own test card numbers in their developer documentation, and those numbers only work in that provider's sandbox. Never mix test data across providers: a number that returns an approval in one sandbox may return an unrecognized-card error in another. Tokenization and vault APIs also ship with test card fixtures that produce deterministic token responses, which is useful for automated test suites.

related article

How to run a test transaction

1. Switch your API keys from live to test mode and confirm the client is pointed at the sandbox host.
2. Pick a test card that matches the outcome you want: success, generic decline, insufficient funds, or expired card.
3. Submit the charge and log the full response object, including decline codes and request IDs.
4. Verify the result appears correctly in your own database, email receipts, and admin dashboard.
5. Repeat with the 3-D Secure variants and with a card that fails validation before it reaches the gateway.

Test scenarios worth covering

• Successful authorization and capture, plus a separate authorization-only flow.
• Hard declines and soft declines, and how your retry logic treats each one.
• Expired card, incorrect CVV, and incorrect postal code responses.
• Duplicate submission, timeout, and network failure mid-request.
• Refunds, partial refunds, and chargebacks against a test charge.
• Currency and locale variation if you sell internationally.

Why real card data is never test data

Real cardholder data, including the PAN, the CVV, and full track data, does not belong in a test environment under any circumstance. The PCI DSS standard forbids storing sensitive authentication data such as the CVV after authorization, and copying production records into staging breaks that rule while widening your breach exposure. Test databases should hold synthetic values only, and any environment that touches real card numbers should sit inside your defined cardholder data environment with the matching controls.

Request cannot be fulfilled

Keeping test data organized

Store your card test data in a shared fixture file or secrets manager rather than in chat threads and screenshots. Label each entry with the outcome it produces, note the provider and API version it belongs to, and review the list when you upgrade SDKs, since scenario behavior can shift between versions. A small, well-documented set of test cards covers more ground than a long list nobody understands.