Lead Sandbox Card
{{ leadCard.display }}
{{ summaryLine }}
{{ selected.label }} {{ batch.length }} cards {{ lengthSummaryBadge }} {{ rngBadgeLabel }} {{ prefixBadgeLabel }} {{ uniqueBatchEnabled ? 'Unique batch' : 'Repeats allowed' }}
{{ presetSummary }}
{{ presetHint }}
Use only with sandbox, demo, and QA systems. Generated values are structurally valid test data, not live payment credentials.
{{ binNotice }}
digits
{{ mask_last }}
Min Max months
Network Number Leading digits Digits CVV Expiry Copy
{{ item.label }} {{ item.display }} {{ item.prefix }} {{ item.length }} {{ item.cvv || '—' }} {{ item.expiry || '—' }}
Metric Value Copy
{{ row.label }} {{ row.value }}
Leading digits Cards Share Digits seen Copy
{{ row.prefix }} {{ row.count }} {{ row.share }} {{ row.lengthsLabel }}
Tags: Devtools , Finance , Randomness
Export to PDF Fullscreen
:

Payment card numbers are structured identifiers, not random strings. They combine issuer ranges, network-specific length habits, and a final checksum digit so systems can catch many typing mistakes before a transaction ever reaches deeper processing. This generator uses that structure to produce synthetic card numbers for testing and demonstration work.

The tool can generate Visa, American Express, Mastercard, Discover, Diners Club, JCB, Maestro, and UnionPay-style numbers. It can also add an optional CVV or expiry, apply display grouping, mask the trailing digits on screen, and build more than one card at a time. The result is practical test data that looks realistic enough for form handling, import flows, table exports, and visual QA without exposing real account details.

That makes the slug useful when you are checking a payment form, seeding a sandbox, demonstrating input masking, or rehearsing exports and dashboards that expect card-shaped data. One run might need a single American Express-style number with a 4-digit security code. Another might need a seeded batch of Visa-like and Maestro-like values so a regression test can be repeated exactly.

The important boundary is structural versus financial validity. A generated number can satisfy the Luhn checksum and still have no relationship to a real, usable account. The package itself says these numbers are for testing and QA only, and that is the right way to read them.

That caution matters operationally too. Replaying large batches against live payment endpoints can resemble card-testing abuse, even when the numbers were generated for innocent reasons. The safe use case is controlled development, demo, and sandbox work.

Everyday Use & Decision Guide:

The simplest use path is to pick a network, choose how many numbers you want, and generate a batch. For many UI checks that is enough. The card-details table, summary tiles, distribution tables, and charts all build from the generated history, so even a small batch gives you material for export and presentation testing.

The advanced controls matter when the test needs to be more specific. A custom BIN or IIN lets you force the leading digits. A length override lets you move away from the network default. The seed control creates a repeatable sequence, which is valuable for screenshots, automated tests, or bug reports where the same dataset needs to be recreated later.

  • Use the display format controls for presentation checks. Grouping with spaces or dashes changes how the number is shown, not the underlying digits.
  • Use masking for demos and screenshots. The display can hide trailing digits while copy actions still use the full unmasked number.
  • Use CVV and expiry only when the receiving form expects them. They are synthetic companion fields, not evidence that a card could authorize.
  • Use the network-prefix enforcement toggle when the starting digits matter. If the custom prefix conflicts with the chosen network and enforcement is turned on, the tool ignores that custom prefix and falls back to a bundled valid range.
  • Remember that history accumulates. Charts and summary tables describe the full generated set in the current session, not just the last click.

A good session usually ends with a predictable test dataset that fits the scenario you are validating. It should not be used to probe production gateways, decline patterns, or fraud controls.

Technical Details:

At the standards level, payment cards are commonly described in terms of an Issuer Identification Number, also called a BIN or IIN, and a Primary Account Number, or PAN. ISO notes that the IIN moved from six digits toward eight-digit assignment while PAN length remains variable. This package uses that general structure as background, then applies its own bundled prefix tables and default lengths per network.

How Generation Works Here

The package chooses a target network, determines a target length, picks a prefix, fills the remaining body with random digits, and computes the last digit with the Luhn checksum rule. The final record stores both the raw number and the display version, and it also rechecks the finished number with the same Luhn validator before saving it to history.

c = (10−(Smod10))mod10

If you provide a custom BIN or IIN, the package first trims it to digits and ensures it leaves room for the final check digit. What happens next depends on the enforcement toggle. With enforcement off, the custom start can be used even if it does not match the chosen network. With enforcement on, a non-matching custom start is discarded and the tool falls back to one of its bundled valid prefixes for that network.

Bundled Network Rules

Network Default length Bundled allowed lengths Display grouping
Visa 16 13, 16, 19 4-4-4-4
American Express 15 15 4-6-5
Mastercard 16 16 4-4-4-4
Discover 16 16, 19 4-4-4-4
Diners Club 14 14, 16 4-6-4
JCB 16 16, 17, 18, 19 4-4-4-4
Maestro 16 12 to 19 4-4-4-4
UnionPay 16 16, 17, 18, 19 4-4-4-4

The length override deliberately sits outside those defaults. In code, the entered value is clamped between 12 and 24 digits, and a value of zero means "use the default for the chosen network." That means you can generate lengths that are unusual for the selected network if your test case is about UI tolerance or validation behavior rather than brand realism.

The CVV and expiry helpers are also generated deterministically from the same random source used for the number body. CVV length follows one of three modes: forced 3 digits, forced 4 digits, or automatic selection where American Express receives 4 digits and the other bundled networks receive 3. Expiry is drawn as a future month within the selected min-to-max month window and returned as MM/YY.

Seeded runs use a custom pseudo-random generator derived from the seed string, so the same inputs produce the same sequence. Unseeded runs use the default random source. That distinction matters when you want reproducible screenshots or stable test fixtures across multiple sessions.

The result surface is broader than the generator button might suggest. The tool stores each record in a history list, then derives network totals, length totals, a pie chart for card family distribution, a bar chart for length distribution, and a JSON representation of the generated data. The details table, network totals table, and length totals table can each be copied or exported, and the chart tabs can be saved as image or CSV files.

All of this logic stays in the browser for this slug. There is no server helper file, which means the generation, checksum calculation, charting, and export preparation are performed client-side.

Step-by-Step Guide:

  1. Choose the card family that best matches the scenario you want to test.
  2. Set the quantity, then decide whether the case needs a custom prefix, a non-default length, a specific display format, or masked output.
  3. Turn on CVV or expiry only if the receiving form expects those fields.
  4. Add a seed when the same batch must be recreated later for QA, documentation, or defect reports.
  5. Generate the set, then review the details table, summary cards, distribution tables, and charts to confirm the output shape matches your test plan.

If the goal is deterministic regression coverage, record the seed and every advanced setting alongside the generated batch. If the goal is a quick demo, the display format and masking controls usually matter more than the exact prefix math.

Interpreting Results:

Every generated row should report a passing Luhn result because the tool constructs the check digit itself and then validates the finished number again. The more useful interpretation questions are about realism, reproducibility, and presentation.

  • If the number looks right but the prefix looks odd: check whether a custom BIN was supplied with network enforcement turned off.
  • If the dataset is not repeatable: confirm that a seed was supplied and that the other advanced controls did not change between runs.
  • If the chart totals look unexpected: remember that history accumulates across runs and can include different networks or different lengths from earlier batches.
  • If the displayed number is masked: copy actions still use the underlying digits, not the bullets shown in the preview.
  • If the expiry or CVV looks realistic: treat that as formatting realism only, not evidence that the record could authorize in a live payment flow.

The safest reading is that the tool produces structurally plausible test data for controlled environments. It does not produce funded accounts, issuer-confirmed credentials, or transaction-ready cards.

Worked Examples:

Regression data for a checkout form

A front-end team may need 20 Visa-style numbers that always regenerate in the same order so screenshots and failure reports stay comparable. In that case the useful settings are the Visa family, a fixed quantity, a seed, grouped display, and no masking. The network and length charts then provide a quick visual check that the dataset stayed consistent across runs.

Testing an American Express branch in a form

If a payment form has a special layout for American Express, the scenario may need a 15-digit number, 4-6-5 visual grouping, and a 4-digit security code. This package can generate that combination directly and, if needed, add a future expiry so the full set of fields can be exercised without touching live card data.

Checking custom-prefix behavior

Suppose you enter a custom start that does not belong to the selected network. With enforcement off, the generated number keeps that start and simply appends a valid Luhn digit. With enforcement on, the tool discards the conflicting start and picks a bundled prefix for the chosen network instead. That is a useful way to test both permissive and strict validation paths.

FAQ:

Do these numbers represent real accounts?

No. They are synthetic values built to match structural rules such as prefix style, length, grouping, and Luhn checksum behavior.

Why does the masked preview still copy full digits?

Masking affects the display string only. The copy actions intentionally use the underlying raw number so the generated data remains usable in a test flow.

Why does the length chart show more than one value when I selected one network?

The history can contain earlier runs with different settings, and some bundled networks also allow more than one default-compatible length or a manual override.

When should I use a seed?

Use a seed whenever the same dataset must be regenerated later. That is especially useful for regression tests, tutorials, screenshots, and debugging.

Why should generated batches stay away from live payment endpoints?

Because repeated structural validation attempts can resemble card-testing traffic to processors and fraud systems. Synthetic numbers belong in controlled QA, sandbox, and demonstration environments.

References: