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 follow a pattern. The opening digits identify an issuer range, the middle digits fill out the account number, and the last digit is a checksum that helps catch common typing mistakes. This generator uses that structure to build synthetic card data for sandbox runs, checkout-form QA, masked demos, and repeatable regression fixtures.

The tool can produce Visa, American Express, Mastercard, Discover, Diners Club, JCB, Maestro, and UnionPay-style numbers in batches of 1 to 100. You can start from a preset, set a custom BIN or IIN, choose whether mismatched prefixes fall back to bundled network ranges, switch the visible grouping, mask the trailing digits on screen, and attach optional CVV or expiry fields. A seed can replay the same batch later, which is useful when a bug report, screenshot, or automated test needs identical sample data.

The important boundary is structural validity, not payment validity. A number can match a network pattern and pass the Luhn checksum while still having no issuing bank, no funding source, and no authorization path. That is why generated values belong in test pages, demos, and controlled sandboxes rather than live payment traffic.

Sandbox rules also vary by provider. Some platforms support generated test ranges, while others want you to use their published test cards or tokens instead. Use this tool to exercise your own forms and data handling, then confirm gateway-specific acceptance rules with the processor you actually integrate.

Technical Details:

A payment card number is usually described as a Primary Account Number, or PAN. The opening issuer digits are the Issuer Identification Number, or IIN, which many teams still call the BIN. ISO explains that IIN assignment has moved from six digits toward eight digits and that PAN length under the revised standard stays within 10 to 19 digits. This generator keeps a practical QA model on top of that standard background by shipping common network ranges, default lengths, and display groupings, then letting you override them when the test case is about form behavior rather than perfect brand realism.

A generated card number is assembled in three parts.
1. IIN / BIN

Leading digits taken from the selected network range or from an accepted custom prefix.

2. Account body

Randomly filled digits that expand the number to the requested total length.

3. Luhn check digit

A final digit computed from the earlier digits so basic checksum validation passes.

After the prefix is chosen, the tool fills the remaining body with random digits and computes one final check digit. That last digit is what makes the finished number pass the same checksum screen used by many payment forms. The tool then validates the completed number again and records whether every row passed.

Formula Core

The checksum rule is compact, but the practical idea is simple: work from right to left across the partial number, double every second digit, subtract 9 whenever doubling creates a two-digit result, add everything together, and choose the final digit that makes the total land on a multiple of 10.

c = (10-(S mod 10)) mod 10
Symbol Meaning How this tool uses it
S Weighted sum of the partial number The sum is built from the chosen prefix plus the generated body digits before the final check digit is added.
c Check digit This is the last digit appended so the completed number passes Luhn validation.
Worked checksum example

If the partial number is 411111111111111, the weighted sum S is 29. The check digit becomes (10 - (29 mod 10)) mod 10 = 1, so the finished number is 4111111111111111.

That example is useful because it shows the job of the last digit clearly. Passing this checksum only means the number is structurally plausible.

Bundled Network Rules

The tool does not try to model every scheme rule in the payment industry. It ships a fixed set of network prefixes, allowed lengths, and display groupings that are broad enough for common QA scenarios.

Network Bundled prefixes Default digits Bundled digits Display grouping
Visa 4 16 13, 16, 19 4-4-4-4
American Express 34, 37 15 15 4-6-5
Mastercard 51-55, 2221-2720 16 16 4-4-4-4
Discover 6011, 622126-622925, 644-649, 65 16 16, 19 4-4-4-4
Diners Club 300-305, 36, 38-39 14 14, 16 4-6-4
JCB 3528-3589 16 16, 17, 18, 19 4-4-4-4
Maestro 50, 56-69 16 12 to 19 4-4-4-4
UnionPay 62 16 16, 17, 18, 19 4-4-4-4

Validation And Limits

Field Current tool rule Why it matters
Batch size 1 to 100 cards Keeps batches manageable for table review and repeatable QA runs.
Length override 0 for network default, or 12 to 24 total digits Useful for field-tolerance testing, but values above current standards are no longer realistic card data.
Custom BIN / IIN Digits only, trimmed so one check digit can still be appended Long prefixes reduce the number of unique combinations available inside a batch.
CVV / CVC mode Auto, forced 3 digits, or forced 4 digits Auto gives American Express 4 digits and the other bundled networks 3 digits.
Expiry window 1 to 120 months ahead Creates future MM/YY values for forms that require an expiry field.
Seed Up to 64 characters The same seed and the same settings replay the same batch in the same order.
Unique batch Warns before generation if the requested unique count exceeds the available combinations Helps you avoid duplicate-heavy runs when the prefix and length space is too small.

One practical detail is easy to miss: each Generate run replaces the current batch. Seeded runs are deterministic, while unseeded runs rely on browser randomness. The metrics and prefix tables therefore describe the present batch only, not a running session history.

Everyday Use & Decision Guide:

Most people do not need every switch at once. Start by choosing the scenario you actually need to test, then keep the rest of the controls quiet unless they answer a specific question about formatting, reproducibility, or prefix handling.

  • Checkout smoke test: use the Checkout QA batch or a plain custom batch when the goal is simply to confirm that a payment form accepts a normal-looking number and preserves the right digit count.
  • Brand-specific branch: switch to American Express, Discover, or another network when your form changes layout, helper text, or validation rules by card family.
  • Demo or screenshot: keep grouped display on and mask the trailing digits so the page looks realistic without exposing the full visible value in the preview.
  • Prefix-rule regression: enter a custom BIN or IIN and decide whether mismatches should be tolerated or forced back to the bundled network ranges.
  • Repeatable fixtures: set a seed whenever you need the same rows again for bug reports, tutorials, or automated tests.

Use the length override carefully. It is helpful when you want to see whether your own field, mask, or storage layer breaks on unusually long input, but a 24-digit result should be read as a stress case rather than a real-world payment-card format.

Step-by-Step Guide:

Use the controls in the same order the tool builds the data so the status badges and result tabs stay easy to read.

  1. Choose a Batch profile at the top if one of the shortcuts matches your scenario. The helper text under the selector explains what that profile loads, and editing the fields later switches the run back to Custom batch.
  2. Set the Network and Batch size, then select Generate. A successful run shows a lead card summary, while a validation warning tells you immediately if the current prefix and length settings cannot support the requested number of unique rows.
  3. Open Advanced when you need more control. Set Custom BIN / IIN, Length override, Display format, Mask trailing digits, and optional CVV or expiry fields to match the form or demo state you want to exercise.
  4. Add a Seed if the dataset must be recreated later, then generate again. The badges in the summary panel should now show either Seeded replay or Browser entropy and should also show whether the prefix came from your custom BIN or from bundled fallback logic.
  5. Read the result tabs in order. Generated Cards shows the visible number shape, Batch Metrics confirms the active preset, network, length rule, and Luhn status, Observed Prefixes groups the leading digits that were actually used, and JSON exposes the raw number plus the display value for downstream fixtures.

When those surfaces match your scenario, you have a batch that is ready for form testing, documentation, or sandbox-only automation.

Interpreting Results:

Read the output in layers. First confirm that the number shape matches the target network and digit count. Then confirm that the metrics reflect the right prefix strategy and replay mode. Only after that should you treat the batch as a good fixture for your own tests.

Output cue What it tells you What it does not prove
Luhn validity The finished number passes the basic checksum rule used by many payment forms. It does not prove the number belongs to a real account or can be authorized.
Leading digits and network The number matches the selected network bundle or the custom-prefix rules you chose. It does not guarantee exhaustive real-world brand detection or issuer assignment.
Digits and observed lengths The batch has the width your current test path expects. It does not guarantee standards-faithful card data when length override is pushing beyond normal ranges.
CVV and expiry The batch can fill companion form fields in a realistic-looking way. These fields are synthetic and are not tied to any live account lifecycle.
Seed and RNG source You can see whether the batch is replayable or one-off. It is not a security promise or a payment-industry audit trail.
Display versus raw number Masked or grouped display affects what you see in the table. It does not change the raw digits used by copy actions or stored in the JSON payload.

The most useful verification cue is agreement between the summary badges, the Generated Cards table, and Batch Metrics. If those surfaces disagree with your test plan, regenerate before you copy the data into another system.

Worked Examples:

Checkout smoke test

A team validating a basic card-number field can load Checkout QA batch, keep the network on Visa, leave extras off, and generate eight unique rows. The result is a clean set of normal-looking numbers for spacing, copy-paste, and input-cleanup checks without introducing expiry or CVV fields that the page does not need yet.

American Express branch bug

If a payment form changes layout for American Express, the AmEx branch pass preset is the fastest route. It gives you a 15-digit shape, 4-digit CVV behavior, and a future expiry so you can confirm that the form handles the longer middle group and the different security-code width in one run.

Prefix-mismatch regression

Suppose a front end should reject a non-Visa prefix while still allowing a Visa-sized number. Keep the network on Visa, enter a custom prefix that does not belong to Visa, and run the test twice. With fallback enabled, the tool uses bundled Visa prefixes instead. With fallback disabled, the generated number keeps your custom start and still gets a valid Luhn digit, which is useful when you need to exercise permissive validation paths.

Length-tolerance stress case

If the question is whether your own field, mask, export layer, or database column breaks on long input, set a custom length above the bundled network range and generate a small batch. The output will still be checksum-valid, but it should be treated as synthetic stress data rather than a realistic payment-card number.

Responsible Use Note:

Generated payment-card data can still create operational problems when it is used carelessly. Keep these batches inside QA, sandbox, training, and clearly labeled demo work.

  • Do not send generated values to live gateways, live fraud systems, or production analytics pipelines.
  • For end-to-end authorization testing, prefer the processor's own published test cards or tokens when that processor provides them.
  • Remember that masking is only a presentation choice. Copy actions and the JSON payload keep the raw digits.
  • After the page loads, number generation and validation stay in the browser, so the tool itself does not post the generated numbers to a server for processing.

That makes the tool well suited to local form checks and sandbox fixtures, but it does not change PCI, processor, or internal data-handling rules in the systems around it.

FAQ:

Does a passing Luhn check mean the card is real?

No. It only means the number matches a checksum rule that many forms use for basic screening.

Will every sandbox accept generated numbers?

No. Some sandboxes accept generated test ranges, while others only accept the provider's own published test cards or payment tokens.

Why was my custom BIN ignored?

If prefix fallback is enabled and the entered prefix does not fit the selected network bundle, the tool discards that mismatch and uses one of its bundled prefixes instead.

What does the seed actually control?

It controls the random sequence. The same seed and the same settings recreate the same batch in the same order.

Does masking change what gets copied or saved in JSON?

No. Masking changes only the visible preview. Copy actions and the JSON tab keep the full raw number.

Why would I generate a 24-digit number if real cards are shorter?

Use that only when you want to stress-test your own field limits or formatting logic. It is a UI tolerance case, not standards-faithful payment data.

Glossary:

Term Meaning in this tool
PAN The full generated payment-card number, including the final check digit.
IIN / BIN The leading issuer-identification digits chosen from the bundled network ranges or from an accepted custom prefix.
Luhn checksum The digit-check rule used to compute and verify the final digit of each generated number.
CVV / CVC An optional synthetic security code added to each generated row for form testing.

References: