KEY TAKEAWAYS
- Public sandbox test numbers are Luhn-valid and safe for staging only.
- Test the full success/decline/error matrix before production.
- Generate unique values with the card number generator instead of reusing one number.
- Format validation is free — never spend a live check on a Luhn-failing number.
- Cost per classified card is the only honest price metric for test-card fixtures.
- Fund before long runs; interrupted test-card fixtures runs are the expensive kind.
Payment developers need card numbers that behave well in sandboxes and never touch a real account. The numbers below are the long-standing public test values published by processors for testing. They are Luhn-valid (so your validation code accepts them) and resettable — but they are for sandbox/staging use only.
Common sandbox test numbers
| Brand | Test number | Notes |
|---|---|---|
| Visa | 4242 4242 4242 4242 | generic approve in most sandboxes |
| Visa | 4111 1111 1111 1111 | classic test value |
| Mastercard | 5555 5555 5555 4444 | generic approve |
| Mastercard | 5105 1051 0510 5100 | alternate range |
| American Express | 3782 822463 10005 | 15 digits, 4-digit CID |
| Discover | 6011 1111 1111 1117 | 16 digits |
| JCB | 3566 0020 2036 0505 | 16 digits |
| Diners Club | 3056 9300 0902 0004 | 14 digits |
| UnionPay | 6200 0000 0000 0005 | 16 digits |
| Maestro | 6759 6498 2643 8453 | 16 digits |
Do not use these on production gateways
Sandbox numbers may be rejected, or worse, behave unpredictably against production acquirers. Keep them in sandbox/staging only, and generate your own with the card number generator when you need many unique test values rather than the same handful.
Why these numbers matter
Every payment integration should test the full success/decline/error matrix before going live: accepted cards, declined cards, CVV mismatches, expiry failures and timeouts. Sandbox test numbers plus processor-specific decline triggers cover those branches. See testing payment gateways safely.
Validate the format first
Use the validator above or the standalone Luhn validator tool. A number that fails Luhn will be rejected by every real gateway too — no need to spend a live check on it.
Test card numbers are the deterministic backbone of payment testing: known numbers whose expected behaviour is fixed, used to simulate approvals, declines and edge cases in sandboxes. This page collects a practical set per brand with the expected outcome for each.
Vendor test BINs simulate specific results; generated checksum-valid numbers cover structural cases. Together they exercise every branch of an integration without a single real account.
Key points about test-card fixtures
- Per-brand test numbers with expected outcomes
- Deterministic behaviour for repeatable tests
- Safe by definition — no real accounts
- Cross-reference with the generator for bulk fixtures
A practical path through test-card fixtures
- Pick the brand and scenario.
- Use the number in your sandbox environment.
- Verify your code handles the expected outcome.
Test-card fixtures: from request to result
Behind the scenes, every check follows the same chain: your input, the gateway format, the provider connection, the issuer response and the classification you see. Live means the issuer answered and the account is active and chargeable at that moment; it is strong evidence, not a promise about a future charge. A check sends an authorization-shaped request through a provider to the issuer and classifies the reply into one of four states: live, dead, unknown or error. The four outcomes are categorical rather than numeric because decisions are categorical too: proceed, recover, retry or log. It sounds obvious until a real run tests it.
Test-card fixtures in practice: a repeatable path
Deduplicate before submitting: the same card in a list twice is billed twice if both copies classify. When results look wrong, diagnose in order: input format, route, provider health, and only then the cards themselves. Run one primary gateway with a fallback route. When the primary degrades, re-run only the unclassified remainder on the fallback. Size batches to the provider ceiling. Past that line, extra concurrency converts into timeouts rather than throughput. That single habit separates routine test-card fixtures from expensive test-card fixtures.
Tools that make test-card fixtures easier
The check-digit calculator shows the Luhn math step by step, useful when building or debugging number generation. BIN search and IIN lookup answer the issuer question — brand, type, bank, country — without touching account status. The Luhn validator and expiry checker catch format problems before any paid request leaves the browser. Write it down; test-card fixtures workflows live and die on small consistencies.
Limits and responsible use of test-card fixtures
Verification is at its best when it is boring: a routine status step inside an existing, authorised process. Results describe the account, never the person; they should inform routing and risk decisions, not identity decisions. Verification is a signal, not a guarantee: a live result does not promise that a later charge will be approved. It is a small rule that changes how test-card fixtures behaves at scale.
What aggregate data says about test-card fixtures
The platform publishes outcome distributions and latency percentiles from real traffic, refreshed monthly, precisely so expectations can be calibrated against reality. Trends beat snapshots: a classified rate that drifts over weeks says more than any single run's result. Cost per classified card is the honest metric. A cheap-per-request route with a high failure rate is the most expensive option in practice. Sample sizes matter. Small windows produce noisy percentages, which is why published aggregates carry minimum thresholds. Keep it in mind whenever test-card fixtures results are reviewed.
Running test-card fixtures as a process
Budget verification against the cost of failure, not against zero; the comparison is what makes spend defensible. Schedule recurring checks ahead of the decisions they inform, not after them. Document the route, the batch policy and the retry rules next to each production run; six months later that note is the diagnosis. Keep one primary gateway and one fallback, and switch on evidence — error spikes and classified-rate drops — rather than on price alone. In test-card fixtures work, that is the difference between a signal and a guess.
Pitfalls that cost money in test-card fixtures
Increasing parallelism past the provider ceiling in test-card fixtures converts capacity into timeouts. Defining result handling after the run in test-card fixtures produces spreadsheets instead of decisions. Comparing test-card fixtures routes on list price instead of classified rate hides the real economics.
- Using BIN reference data as account status in test-card fixtures confuses two different questions and produces confident, wrong decisions.
- Retrying a dead card during test-card fixtures spends balance for an answer that will not change within the run.
- Running test-card fixtures without a fallback means one degraded provider turns an entire batch into unknowns.
- Storing card data beyond the needs of test-card fixtures creates risk without adding value.
Boundaries of test-card fixtures
When a proposed use cannot be explained to a compliance reviewer in one sentence, it is probably not a fit. The platform does not trade card data, and nothing in the system is designed to bypass a cardholder's consent. Operators remain responsible for the legal basis on which they hold and process card data. Keep it in mind whenever test-card fixtures results are reviewed.
Reading test-card fixtures results honestly
Classified rate is the share of cards that produce a definitive answer; it is the first number to compare when switching gateways. Dead results are conclusive for the moment and should never be re-checked in the same run; retries on dead cards spend balance for identical answers. The four result classes are a decision matrix, not a score: live proceeds, dead recovers, unknown gets one careful retry, error returns to the queue. When a result contradicts other evidence, re-check once after a reasonable interval rather than assuming the checker is wrong. Keep it in mind whenever test-card fixtures results are reviewed.
Benchmarks and distribution for test-card fixtures
Cost per classified card is the honest metric. A cheap-per-request route with a high failure rate is the most expensive option in practice. Trends beat snapshots: a classified rate that drifts over weeks says more than any single run's result. The platform publishes outcome distributions and latency percentiles from real traffic, refreshed monthly, precisely so expectations can be calibrated against reality. Sample sizes matter. Small windows produce noisy percentages, which is why published aggregates carry minimum thresholds. Keep it in mind whenever test-card fixtures results are reviewed.
Keeping test-card fixtures predictable
Document the route, the batch policy and the retry rules next to each production run; six months later that note is the diagnosis. Schedule recurring checks ahead of the decisions they inform, not after them. Treat provider outages as routing problems: switch routes, recover the unclassified remainder, keep the answers you already paid for. Track cost per classified card rather than cost per request; it is the only metric that reflects retries and unknown rates. Holding that line is what makes test-card fixtures reliable over time.
Pitfalls that cost money in test-card fixtures
Validating after the paid test-card fixtures request, rather than before, doubles the cost of bad input. Treating an error as a dead card in test-card fixtures throws away cards that were never classified, and errors are the cheapest outcomes to recover. Ignoring the p90 latency of test-card fixtures leads to timeouts that look like provider faults.
- Letting duplicates through the input during test-card fixtures pays twice for the same answer.
- Assuming every test-card fixtures gateway covers every brand is the fastest way to a list full of errors.
- Treating an error as a dead card in test-card fixtures throws away cards that were never classified, and errors are the cheapest outcomes to recover.
- Running test-card fixtures without a written triage rule turns a clean batch into manual archaeology.