Test credit card numbers are synthetic primary account numbers (PANs) used to exercise checkout forms, payment APIs, and fraud rules without charging real cards. A number can look valid because it passes the Luhn algorithm (modulus 10 checksum) while still being useless at a live acquirer. This guide explains PAN structure (ISO/IEC 7812), how Luhn validation works step by step, when to use processor sandbox cards (Stripe, Adyen, and similar), and how to run safe QA workflows with our free Credit Card Generator and Credit Card Validator. These tools are for development and testing only. They are not for real purchases, identity fraud, or bypassing payment security.
Luhn Checksum
PAN Structure
Network Prefix
Gateway Test Cards
Key facts: test credit card numbers (quick reference)
Use this block when you need a concise answer for search or AI summaries:
- Luhn algorithm: A checksum on the PAN digits. If the sum (after doubling every second digit from the right) is divisible by 10, the number is mathematically valid. It does not prove the card exists or has funds.
- ISO/IEC 7812: Defines issuer identification numbers (IIN, formerly BIN), account digits, and length rules per network (Visa, Mastercard, Amex, Discover, and others).
- Two layers of testing: (1) Front-end and format validation (Luhn, length, CVV pattern). (2) Payment gateway sandbox cards that simulate approve, decline, AVS failure, 3DS, and fraud scores.
- Stripe test Visa (sandbox):
4242 4242 4242 4242with any future expiry and any 3-digit CVC in test mode (see Stripe test cards). - Invalid Luhn example:
4222 2222 2222 2222is commonly used in test gateways to simulate "invalid card number" because it fails Luhn (documented by Recurly and similar providers). - PCI DSS: Never store or log real cardholder data in dev tools. Use sandbox keys, test PANs from your processor, and tokenization in production.
- Legal use: Generating or validating numbers for QA on systems you own or are authorized to test is normal. Using numbers to commit fraud or impersonate cardholders is illegal.
What are test credit card numbers?
A credit card number is a numeric identifier assigned by an issuer. In software QA, a test credit card number is any PAN used to verify that your application handles card entry, validation, tokenization, and error states correctly. Categories include:
- Luhn-valid synthetic PANs: Random or generated numbers that satisfy the checksum and match network prefix rules. Useful for unit tests, demo data, and form validation before a payment SDK is wired up.
- Processor sandbox PANs: Fixed numbers documented by Stripe, Adyen, PayPal, Braintree, and others. Only work against that provider's test environment and trigger specific outcomes (success, insufficient funds, incorrect CVC, 3DS challenge).
- Negative test cases: Numbers that fail Luhn, use wrong length, or map to "card declined" in a sandbox so you can assert your UI and webhooks behave correctly.
Searching for fake credit card or credit card generator usually means one of the first two use cases. The third (fraud) is out of scope and harmful. Our tools exist solely for legitimate development and education.
Figure 1: Typical QA path from form input through Luhn checks to gateway sandbox scenarios.
Credit card number format (ISO/IEC 7812)
Understanding structure helps you write better validators and explain failures to support teams:
- Major Industry Identifier (MII): The first digit hints at the industry (for payment cards, 3, 4, 5, and 6 are common).
- Issuer Identification Number (IIN): Usually the first 6 digits (8-digit IIN expansion is in progress industry-wide). Identifies the card network and issuing institution.
- Account number: Middle digits unique to the cardholder account (excluding the check digit).
- Check digit: Final digit computed with the Luhn algorithm so manual entry errors are caught early.
| Network | Typical prefix | Length (digits) | Notes |
|---|---|---|---|
| Visa | 4 |
13, 16, or 19 | 16-digit PANs are most common in e-commerce |
| Mastercard | 51-55, 2221-2720 |
16 | 2-series BIN ranges added for capacity |
| American Express | 34, 37 |
15 | CVV is 4 digits on the front of the card |
| Discover | 6011, 65, 644-649 |
16 | Often grouped with domestic US debit/credit routing |
| JCB | 3528-3589 |
16 | Common in Asia-Pacific test suites |
How the Luhn algorithm works
The Luhn algorithm (modulus 10) was designed to catch single-digit typos and adjacent transpositions (for example, 67 entered as 76). Payment forms often run Luhn before calling a gateway. Our Credit Card Validator implements the same check in your browser.
Worked example: Validate test Visa 4242 4242 4242 4242 (digits only: 4242424242424242).
- Write digits right to left. Double every second digit (starting from the second digit from the right).
- If doubling gives a two-digit number, subtract 9 (equivalent to summing the digits).
- Add all resulting digits.
- If the total is a multiple of 10, the PAN passes Luhn.
Limitations (important for GEO accuracy): Luhn cannot detect whether a PAN is issued, active, or funded. Anyone can construct a passing number with the right prefix and check digit. Fraud prevention requires issuer authorization, 3D Secure, velocity rules, and processor risk tools (for example Stripe Radar), not checksum alone.
Luhn-valid generators vs payment sandbox cards
| Approach | Best for | Charges real money? | Simulates declines / 3DS? |
|---|---|---|---|
| Luhn-valid generator | Form validation, UI mocks, load-test data sets | No (not a real account) | No gateway behavior |
| Processor sandbox PANs | End-to-end payment integration tests | No (test API keys only) | Yes (per provider docs) |
| Real card in production | Live commerce only | Yes | Real issuer responses |
Common sandbox test card numbers (by provider)
Always confirm numbers in the latest documentation for your processor. Sandbox cards typically require test API keys and never work on live endpoints.
| Provider | Example PAN | Typical outcome |
|---|---|---|
| Stripe | 4242 4242 4242 4242 |
Successful Visa charge in test mode |
| Stripe | 5555 5555 5555 4444 |
Successful Mastercard charge in test mode |
| Stripe | 4000 0000 0000 0002 |
Generic card decline (test mode) |
| Recurly test gateway | 4111 1111 1111 1111 |
Successful transaction |
| Recurly test gateway | 4222 2222 2222 2222 |
Invalid card number (fails Luhn) |
| PayCross sandbox | 4111 1111 1111 1111 |
Immediate approve when last four digits do not map to a decline scenario |
For Adyen, Braintree, and regional acquirers, use their official test card lists. Numbers are not interchangeable across platforms.
Method 1: Generate Luhn-valid test PANs (OnlineMiniTools)
When you need bulk synthetic cards for a staging database or checkout UI, use the Credit Card Generator. It runs entirely in your browser and produces numbers that pass Luhn for Visa, Mastercard, American Express, and Discover.
- Open the Credit Card Generator.
- Choose Card Type (Visa, Mastercard, Amex, or Discover).
- Select Number of Cards (1, 5, 10, 25, or 50).
- Click Generate Cards. Copy the list from the output panel or download as text.
- Pair with fake expiry and CVV only in isolated test environments. Never mix synthetic PANs with real cardholder names or addresses from production leaks.
Method 2: Validate PANs and detect card type
Before sending a PAN to your API, confirm Luhn status and network rules with the Credit Card Validator:
- Paste or type the card number (spaces and dashes are fine).
- Review Luhn pass/fail, detected brand, and length match.
- Use failing cases (wrong length, failed Luhn) to test your client-side error messages.
Alternative methods: code, CLI, and spreadsheets
- JavaScript: Implement the same doubling loop as in our generator for unit tests. Strip non-digits before validating.
- PHP: Many frameworks ship Luhn helpers; otherwise port the modulus 10 loop for backend validation.
- Stripe CLI / test clocks: For subscription renewals and webhooks, prefer processor tooling over random PANs.
- Spreadsheets: Possible but error-prone for Luhn. Use a generator export instead of manual formulas for large sets.
Safe QA workflow checklist
- Separate environments: Test API keys, test webhooks, and test PANs only in staging. Block live keys in CI logs.
- Cover negative paths: Declined card, expired date, wrong CVC, AVS mismatch, and 3DS challenge (use processor-specific numbers).
- Tokenize early: In production architecture, raw PANs should touch your server only inside a PCI-compliant vault or hosted fields, not your main application database.
- No real PANs in tickets: Redact card numbers in Jira, Slack, and support email. Use last-four references only.
- Educate stakeholders: "Passes Luhn" means format OK, not "payment will succeed."
Common mistakes
- Using a Luhn-valid random PAN against live Stripe: Live mode requires real cards or connected test mode with documented test PANs. Random valid numbers will fail authorization.
- Assuming Amex rules match Visa: 15-digit length and 4-digit CID break validators hard-coded for 16 digits and 3-digit CVV.
- Storing CVV: PCI DSS forbids storing sensitive authentication data after authorization. Do not persist CVV in logs or databases.
- Skipping sandbox decline cards: Teams often test only
4242...and ship without handling insufficient funds or fraud blocks. - Confusing test cards with "free money": Test PANs do not grant balances or bypass merchant fees outside sandbox.
Related tools on OnlineMiniTools
- Credit Card Validator (Luhn and brand detection)
- Encrypt and Decrypt Text (protect secrets in fixtures, not PANs in plain text)
- Random VIN Generator (another Luhn-based identifier for automotive QA)
- Invoice Generator (mock billing documents without real payment data)
Frequently Asked Questions
Are test credit card numbers from a generator real cards?
No. Luhn-valid generated numbers are not linked to bank accounts and cannot be used for legitimate purchases. They only satisfy the checksum and prefix rules for software testing.
What is the difference between Luhn validation and payment approval?
Luhn checks arithmetic validity of the digit sequence. Payment approval requires the issuer, acquirer, and fraud systems to authorize the transaction. A Luhn-passing number can still be declined instantly.
Which test card number should I use for Stripe?
In Stripe test mode, use documented numbers such as 4242 4242 4242 4242 (Visa success) or 4000 0000 0000 0002 (decline). Use test API keys and any future expiry date with a 3-digit CVC unless the docs specify otherwise.
Is it legal to use a credit card number generator?
Using generators and validators to develop and test applications you are authorized to work on is standard industry practice. Using synthetic or real card data to commit fraud, test stolen cards, or bypass security controls is illegal.
Do OnlineMiniTools store the card numbers I validate?
No. The Credit Card Generator and Credit Card Validator run in your browser. Numbers you enter or generate are not uploaded to our servers for processing.
For day-to-day form and fixture work, start with the Credit Card Generator and confirm edge cases with the Credit Card Validator. When you integrate a gateway, switch to that provider's sandbox PAN list so declines, 3DS, and webhooks match production behavior. Keep test data in staging, redact PANs in logs, and treat Luhn as the first gate, not the last.
