Free tool · Test data

Credit card generator for testing

Valid test card numbers for 11 networks, with expiry dates, CVVs, PINs and full cardholder details, in bulk. Add invalid cards for negative tests, check any number, and export to CSV, JSON, XML, SQL or Gherkin.

Credit card generatorFree

LiveLocal only

Card numbers that pass the Luhn check for eleven networks, with expiry date, CVV, PIN and cardholder details, for testing payment forms and seeding test data. Nothing leaves your browser.

Networks

Rows cycle through the networks you choose. At least one stays selected.

How many

1 to 1,000.

Seed

The same seed always gives the same cards.

Number length

Every valid length adds 13 and 19-digit Visa, 14 to 19-digit UnionPay and more.

Invalid cards for negative tests

Wrong check digit, too short, or expired. Each is marked Reject.

Expiry and security code

Expiry date

Random dates fall within the next five years.

Expiry format

CVV

American Express uses four digits, every other network three.

Cardholder and output

Extra columns

Names, emails, phone numbers and addresses come from the test data generator: undeliverable emails and, outside India, phone numbers in reserved fictional ranges.

Cardholder country

Sets names, phones and addresses, not the card number.

Number format

SQL always stores digits only.

Table name, for SQL

Used in the SQL INSERT export.

10 cards

Export

Opens in Excel, Google Sheets or any CSV import.

Generated card numbers
Card number	Network	Expiry	CVV	Cardholder name	Expected
4366 1268 2006 3116	Visa	06/28	495	OSCAR WHITE	Accept
2720 9722 4268 3907	Mastercard	01/27	377	FREYA EVANS	Accept
3409 198241 96877	American Express	10/29	4577	EMILY JOHNSON	Accept
4109 9114 5298 0964	Visa	04/31	255	OLIVIA MOORE	Accept
2500 0994 4028 9513	Mastercard	04/27	498	LOUISE MICHEL	Accept
3469 051662 23191	American Express	08/28	0339	WILLOW SMITH	Accept
4420 1918 9111 3905	Visa	03/28	055	TANVI DESAI	Accept
2300 8546 7134 4110	Mastercard	07/28	044	MATTHEW THOMAS	Accept
3731 289871 23955	American Express	05/28	9445	DAVID MARTIN	Accept
4031 1030 6405 0302	Visa	11/28	345	MICHAEL WILLIAMS	Accept

For form and data tests only. These numbers pass format checks, but a payment gateway declines them. To test real payment outcomes in a sandbox, use the published test cards for Stripe, Razorpay, Braintree and Adyen.

Check a card number

Paste any number to see its network, length and Luhn result, check by check.

Card number

Spaces and hyphens are ignored. Never enter a real card number here or in any other testing tool.

Enter a card number to check it.

ReadyRuns in your browser. Nothing you enter is uploaded.Exports: CSV, JSON, SQL, Gherkin

How to use

How to use the credit card generator

1Choose the networks you need. Rows cycle through them, and every number is recognised as the network it was made for.
2Set how many cards to make, up to 1,000, and whether to use each network’s standard length or every length it issues.
3Pick the expiry date, its format and the CVV, then add the columns your form needs: cardholder name, email, phone, billing address or PIN.
4Add invalid cards if you are testing rejection, then copy a single number or export the set as CSV, JSON, XML, SQL, Gherkin, Markdown or plain text.
5Paste any number into Check a card number to see its network, length and Luhn result, check by check.

Guide

Card numbers, explained

What each option does

Every option maps to something a real payment form has to handle. Together they cover the inputs a checkout sees, the valid ones and the ones it must refuse.

Networks
Visa, Mastercard, American Express, Discover, RuPay, JCB, Diners Club, UnionPay, Maestro, Mir and Troy. Each number uses a prefix only that network uses, so card-type detection and logos can be tested reliably.
Number length
Standard gives each network’s usual length. Every valid length adds the others it issues, such as 13 and 19-digit Visa and 12 to 19-digit Maestro, which catches fields that assume every card has 16 digits.
Invalid cards
Mixes in cards with a wrong check digit, a number that is too short, or an expiry date in the past, each marked Reject with the reason, so one export holds both your positive and negative cases.
Expiry date and format
A random date within five years, or the same fixed month and year for every card. Output as MM/YY, MM/YYYY or YYYY-MM, to match the format your form or API expects.
CVV
Random, the standard 123 (1234 for American Express) that is easy to type during manual testing, or none at all for flows that do not ask for it.
Extra columns and country
Cardholder name, email, phone, a full billing address and a 4-digit PIN, localised for India, the United States, the United Kingdom, Germany, France or Australia, for address verification and checkout tests.
Seed
The same seed, options and count always give the same cards. Note it in a bug report so anyone can regenerate the exact data that failed.

How a card number is built

A payment card number, formally the primary account number or PAN, follows the ISO/IEC 7812 standard. It has three parts. The first six to eight digits are the issuer identification number, usually called the BIN, which identifies the network and the bank that issued the card. The digits after it identify the account. The last digit is a check digit, calculated from all the others with the Luhn algorithm.

The very first digit is the major industry identifier. It says which kind of organisation issued the card, which is why every card in your wallet starts with 3, 4, 5 or 6.

1 and 2
Airlines, and other future industry assignments. Mastercard’s 2-series (2221 to 2720) and Mir (2200 to 2204) also start with 2.
3
Travel and entertainment: American Express, Diners Club and JCB.
4 and 5
Banking and financial: Visa on 4, Mastercard on 51 to 55, and Maestro on parts of 50 and 56 to 58.
6
Merchandising and banking: Discover, UnionPay, RuPay and Maestro.
7, 8 and 9
Petroleum, healthcare and telecoms, and national assignments. Troy in Turkey uses 9792, and RuPay also issues on 81 and 82.

Card networks: prefixes, lengths and security codes

Each network has its own leading digits, card lengths and name for the security code. The generator uses the prefixes below, chosen so that no two networks overlap, which matters because a payment form usually decides the network from the first few digits as the user types.

Visa
Starts with 4. Usually 16 digits, also 13 and 19. 3-digit CVV2.
Mastercard
Starts with 51 to 55, or 2221 to 2720. 16 digits. 3-digit CVC2.
American Express
Starts with 34 or 37. 15 digits. 4-digit CID printed on the front of the card.
Discover
Starts with 6011 or 644 to 649 (and 65, shared with RuPay). 16 to 19 digits. 3-digit CID.
RuPay
India’s domestic network. Starts with 508 or 606 to 608 (and 60, 65, 81 and 82). 16 digits. 3-digit CVV.
JCB
Starts with 3528 to 3589. 16 to 19 digits. 3-digit CAV2.
Diners Club
Starts with 36, 38 or 300 to 305. 14 digits, and 16 on some newer cards. 3-digit CVV.
UnionPay
Starts with 62. 16 to 19 digits. 3-digit CVN2.
Maestro
Debit, mostly in Europe. Starts with 5018, 5020, 5038, 6304, 6759, 6761 or 6763. 12 to 19 digits. 3-digit CVC2.
Mir
Russia’s domestic network. Starts with 2200 to 2204. 16 to 19 digits. 3-digit CVP2.
Troy
Turkey’s domestic network. Starts with 9792. 16 digits. 3-digit CVV.

The Luhn check, step by step

The Luhn algorithm, patented by IBM scientist Hans Peter Luhn in 1960, catches almost every single-digit typo and most swaps of two neighbouring digits. Starting from the rightmost digit and moving left, double every second digit. Where doubling gives a number over 9, subtract 9. Add up all the digits. If the total is a multiple of 10, the number passes.

Take 4539 1488 0343 6467. Counting from the right, the digits to double are 6, 6, 4, 0, 8, 1, 3 and 4, which become 3, 3, 8, 0, 7, 2, 6 and 8 and add up to 37. The digits left alone, 7, 4, 3, 3, 8, 4, 9 and 5, add up to 43. The total is 80, a multiple of 10, so the number passes. Change any one digit and the total moves off a multiple of 10.

A generator works the other way round. It builds every digit except the last, runs the same sum with the positions shifted by one, and picks the check digit that brings the total to a multiple of 10: here the first fifteen digits give 73, so the check digit is 7. Passing the check means only that a number is well formed. It says nothing about whether an account exists.

JavaScript

// True when a card number passes the Luhn check
function luhnValid(number) {
  const digits = number.replace(/\D/g, '')
  let sum = 0
  for (let i = 0; i < digits.length; i++) {
    let d = Number(digits[digits.length - 1 - i])
    if (i % 2 === 1) {
      d *= 2
      if (d > 9) d -= 9
    }
    sum += d
  }
  return digits.length > 1 && sum % 10 === 0
}

luhnValid('4539 1488 0343 6467') // true

Python

def luhn_valid(number: str) -> bool:
    digits = [int(c) for c in number if c.isdigit()]
    total = 0
    for i, d in enumerate(reversed(digits)):
        if i % 2 == 1:
            d *= 2
            if d > 9:
                d -= 9
        total += d
    return len(digits) > 1 and total % 10 == 0

def check_digit(partial: str) -> str:
    """The digit that makes partial + digit pass the Luhn check."""
    return next(str(d) for d in range(10) if luhn_valid(partial + str(d)))

luhn_valid("4539 1488 0343 6467")  # True
check_digit("453914880343646")     # "7"

Expiry dates and security codes

A card is valid until the last day of its expiry month, so a card marked 10/26 still works on 31 October 2026. Forms that compare the expiry with today’s date instead of the end of the month wrongly reject cards in their final month, which is worth a test of its own. Two-digit years also need care: a form must read 30 as 2030, not 1930.

The security code has a different name on every network, CVV2 on Visa, CVC2 on Mastercard, CID on American Express and Discover, CAV2 on JCB and CVN2 on UnionPay, but it does the same job: it proves the card is in the buyer’s hands. American Express prints four digits on the front; everyone else prints three on the back. PCI DSS forbids storing the security code after authorisation, even encrypted, so check that your system never writes it to a database or a log.

Generated numbers, test cards and virtual cards

These three are often confused, and they do very different jobs. Generated numbers, like the ones on this page, are random numbers that pass the Luhn check. They are for everything before the payment gateway: field validation, network detection and logos, input masks, length limits, CVV length and seeding databases or load tests with realistic card data. A gateway declines them.

Published test cards are numbers that payment providers such as Stripe, Razorpay, Braintree and Adyen document for their sandboxes. They work only in test mode and trigger set outcomes: a successful payment, a decline for insufficient funds, a 3D Secure challenge or a dispute. Use them to test the payment itself.

Virtual cards are real cards. Banks and card providers issue them, linked to a real account, for shopping online without exposing your main card number. No generator can create one, and a site that promises a free virtual card with a balance, or one that passes verification for a free trial, is offering fraud or running a scam.

What to test on a payment form

Generated cards cover most of the checks a payment form needs before it ever calls the gateway. Work through these with a mixed set, including invalid cards.

Network detection
The right logo appears after the first few digits for every network you accept, and an unsupported network gets a clear message, not a silent failure.
Length rules
15-digit American Express and 19-digit Visa, Discover and UnionPay numbers are accepted. A field capped at 16 characters rejects real customers.
Input masks
Visa groups as 4-4-4-4, American Express as 4-6-5. Pasting a number with spaces or hyphens works, and the caret does not jump when editing the middle.
Luhn validation
A number with a wrong check digit is rejected on the field, with a message that says the number is invalid rather than that the payment failed.
Expiry handling
Expired cards are rejected, the current month is accepted, and every format the form allows is read correctly.
Security code
Four digits are accepted for American Express and three for everyone else, and the code is never shown back, stored or logged.
Billing address
International addresses, postcodes with letters and spaces, and names with accents all pass validation and reach the gateway intact.
Mobile and accessibility
The number field opens the numeric keyboard, supports autofill, and every error is announced to screen readers next to the field it belongs to.
Data handling
Only the last four digits are ever displayed, full numbers never appear in URLs, analytics or logs, and test databases contain no real card data.

Negative tests worth running

A payment form should reject bad input clearly, before it reaches the gateway. Turn on invalid cards to get these mixed into the set, each marked Reject with the reason.

Wrong check digit
One digit changed, so the Luhn check fails. The form should say the number is invalid, not send it.
Too short
A number below the network’s shortest length. Check the error appears on the field, not after submitting.
Expired date
A month in the past. The form should reject it, and the message should mention the date, not the card number.
Spaces and hyphens
Paste a grouped number into a field that strips spaces, and a digits-only number into one that formats as you type.
Four-digit CVV
American Express uses four digits. A form that limits every CVV to three blocks Amex customers.

Using generated cards in automated tests

Export the set as JSON for fixtures, or as Gherkin for a data-driven scenario, and drive the checkout form with each row. Keep the seed in the test so the data is the same on every run. The Expected column tells each test whether the form should accept or reject the card.

Playwright (TypeScript)

import { test, expect } from '@playwright/test'
import cards from './test-cards-10.json'

for (const card of cards) {
  test(`card ${card.card_number} is ${card.valid ? 'accepted' : 'rejected'}`, async ({ page }) => {
    await page.goto('/checkout')
    await page.getByLabel('Card number').fill(card.card_number)
    await page.getByLabel('Expiry date').fill(card.expiry)
    await page.getByLabel('Security code').fill(card.cvv)
    await page.getByRole('button', { name: 'Pay' }).click()
    if (card.valid) {
      await expect(page.getByText('Card number is invalid')).toBeHidden()
    } else {
      await expect(page.getByRole('alert')).toBeVisible()
    }
  })
}

Safe and responsible use

Generated numbers are random. One may happen to match a real card’s number, but it comes with no real expiry date, security code or cardholder, and a payment gateway declines it. Never use a generated number to buy anything, start a free trial, verify an account or get around a payment check. That is fraud, whatever the number, and payment providers flag and block it.

This generator deliberately has no way to enter a bank’s own prefix, and no export in the number, month, year and code layout that stolen card lists use. Producing numbers inside one issuer’s range is what card fraud tools do, and testing a form never needs it. Everything runs in your browser and nothing is sent anywhere.

Generated data also helps with compliance. PCI DSS forbids real card numbers in test environments, so seeding test databases, fixtures and demo accounts with generated numbers keeps real cardholder data out of them.

Use it alongside

QAble service

Banking and payments testing

QAble tests payment flows end to end, from card field validation and 3D Secure to declines, refunds, webhooks and disputes.

Explore the service

FAQ

Frequently asked questions

What is a credit card generator?

A tool that creates card numbers which follow the rules a real number follows: the right prefix and length for its network and a valid Luhn check digit. Developers and testers use them to test payment forms and fill test databases without using real card data.

Are the generated credit card numbers real?

No. They are random numbers that pass the Luhn check for a network. They have no account behind them, no real expiry date or security code, and a payment gateway declines them.

Is it legal to use a credit card generator?

Generating numbers to test software, fill test databases or learn how card numbers work is legal and routine. Using any card number you are not authorised to use to obtain goods, services or a free trial is fraud, wherever the number came from.

Can I use a generated card for a free trial, PayPal or account verification?

No. These checks contact the issuing bank, which declines a number with no account behind it, and attempting it is fraud. For a trial, use your own card or a virtual card from your bank, which keeps your main number private.

Do generated cards have money or a balance on them?

No. A generated number is not linked to any account, so there is no balance to spend. Sites that promise a generated card with money on it are scams.

Why does Stripe decline a generated number?

Because it is not one of Stripe’s published test cards. In test mode Stripe only accepts its own test numbers, such as 4242 4242 4242 4242. Use the published test cards to test payment outcomes, and generated numbers to test your form.

What makes a credit card number valid?

Three things a form can check: a prefix that belongs to a network, a length that network issues, and a check digit that passes the Luhn algorithm. A valid number is well formed. Only the issuing bank can say whether an account exists.

Can I generate card numbers for a specific bank or BIN?

No, on purpose. Generating numbers inside one issuer’s range is a technique used in card fraud, and testing a payment form never needs it. Choosing the network gives you everything form validation depends on.

Which card networks can I generate?

Visa, Mastercard, American Express, Discover, RuPay, JCB, Diners Club, UnionPay, Maestro, Mir and Troy, at their standard length or at every length each network issues, with the right security code length for each.

Can I generate Indian test cards, such as RuPay?

Yes. Choose RuPay for India’s domestic network, and set the cardholder country to India for Indian names, phone numbers and addresses. For payments in a Razorpay sandbox, use Razorpay’s published test cards instead.

What is a CVV, and how is it generated here?

The card security code printed on the card, three digits on most networks and four on the front of American Express. Here it is random, the easy-to-type 123 (1234 for Amex), or left out. A real CVV is calculated by the issuer from secret keys, so no generator can produce a real one.

Can I get the same cards again?

Yes. The seed fixes the output, so the same seed, options and count always give the same cards. Random expiry dates are counted from the current month, so they move forward over time.

Is anything I generate or check sent to a server?

No. The numbers, the checks and the exports are all made in your browser. Nothing is uploaded or stored.

Need the edge cases found for you?

QAble testers work through the inputs, payment paths and data that break products in production, before your users find them.

Talk to QA Advisor

Credit card generator for testing

Check a card number

How to use the credit card generator

What each option does

Networks

Number length

Invalid cards

Expiry date and format

CVV

Extra columns and country

Seed

How a card number is built

1 and 2

3

4 and 5

6

7, 8 and 9

Card networks: prefixes, lengths and security codes

Visa

Mastercard

American Express

Discover

RuPay

JCB

Diners Club

UnionPay

Maestro

Mir

Troy

The Luhn check, step by step

Expiry dates and security codes

Generated numbers, test cards and virtual cards

What to test on a payment form

Network detection

Length rules

Input masks

Luhn validation

Expiry handling

Security code

Billing address

Mobile and accessibility

Data handling