Card Test Data Source
Uncover the truth about card test data sources and find the perfect solution for your needs.
Card Test Data Sample: Guide to Sandbox Card Numbers
Card test data samples are fake card numbers and checkout details that payment processors publish for developers to test payment flows in sandbox mode. The numbers pass format checks such as the Luhn algorithm, but they cannot charge a real account. Each processor ships its own set, and those numbers stop working the moment you switch to live API keys.
What fields does a card test data sample include?
A usable test record covers every field your checkout form collects. Skip one field and the test fails for the wrong reason, which hides real bugs.
Unable to produce this content
- PAN: a 16-digit number taken from the processor's documented list.
- Expiry date: a future month and year, often a fixed value set by the processor.
- CVV: any three digits for most gateways (four for American Express).
- Cardholder name: a placeholder string such as Test User.
- Billing ZIP and country: values that match the address rules your gateway enforces.
Why do test card numbers pass validation?
Most test PANs satisfy the Luhn checksum, the same mod-10 check real cards pass. Your client-side validation, brand detection, and number formatting all behave as they would with a live card. The number is valid in shape, not in authority.
Where do card test data samples come from?
Processors publish their own lists in developer docs, and the sets differ from gateway to gateway.
- Stripe documents 4242 4242 4242 4242 as its baseline Visa test card, plus cards for specific decline codes.
- Adyen publishes a table of test cards that trigger named refusal reasons.
- PayPal and Braintree issue sandbox accounts with linked test card values.
- Square lists test values inside its developer dashboard after you create an application.
Use the list from the processor you actually integrated. A number from one gateway may return an "unknown card" error on another, which wastes an afternoon.
How do you test declines and 3-D Secure with sample cards?
Happy-path payments are the easy half. The value of a good sample set is that it lets you reproduce failures on demand.
Testing declines
Most processors assign a test PAN to each common decline: insufficient funds, lost card, expired card, do-not-honor, and processing error. Fire each one through your checkout and confirm that your error copy matches what the customer should see. Check that your order records the failure and does not mark the order as paid.
Testing 3-D Secure and authentication
Processors provide test cards that force a challenge, a successful authentication, or an authentication failure. Run all three so you know how your code handles a customer who abandons the challenge window. Sandbox CVV checks are loose, so test the CVV rejection path with a dedicated card rather than a guessed number.
What separates test card data from real card data?
Authority and legal status. A test PAN is issued for simulation and routes to no account. A real PAN plus CVV is live payment credentials, and handling it in a test system breaks PCI DSS.
PCI DSS requires that production cardholder data stay out of development and test environments. Teams that restore a production database into staging "for realistic data" create a breach risk and fail an audit in the same move. Generate synthetic records instead.
How should a team store and manage card test data?
- Keep test values in a seed file or fixture, versioned with your code.
- Label every sandbox config with a clear key prefix so a live key cannot slip into a test run.
- Guard against accidental live charges with a check that blocks live keys when an environment flag is set.
- Review the fixture file when you upgrade a gateway SDK, since processor test sets change.
- Never commit a real card number to a repo, a ticket, or a screenshot, even in a bug report.
Frequently asked questions
Can I use test card numbers on a live site?
No. Test PANs are rejected by live processing. Running one through a production terminal returns an error, and repeated attempts can flag the account.
Are test CVV values real?
No. In sandbox mode most gateways accept any three-digit CVV, or a single designated value. Nothing is checked against an issuer.
Do test cards expire?
Some do. A few processors pin a fixed expiry far in the future, while others expect you to enter any future date. Check the docs for the card you use so an expired fixture does not fail your suite.
Is using test card data legal?
Yes, when you use published sandbox values against your own merchant account in a test environment. The numbers are documentation, not credentials, and they move no money.
How many test cards do I need?
Four or five covers most suites: one success case per major brand you accept, one soft decline, one hard decline, and one card that forces 3-D Secure.