{{ summaryHeading }} {{ summaryValue }} {{ summaryLine }} {{ validCount }} / {{ cardCount }} Luhn-valid {{ networkLabel }} Seed {{ params.seed }}
{{ actionAnnouncement }}
Synthetic payment-card fixture settings
Start from a common form-test setup or keep custom settings.
This controls format shape only; it does not create a processor-recognized scenario card.
Use one for a quick form check or a small batch for fixture and table coverage.
Optional digits only. Never paste a real PAN or customer identifier here.
Choose plain digits, spaces, or dashes for screenshots and paste testing.
Leave off unless the form branch needs a security-code field.
{{ params.include_cvv ? 'On' : 'Off' }}
Leave off unless the form branch needs an expiry field.
{{ params.include_expiry ? 'On' : 'Off' }}
{{ workflowFeedback }}
Use 0 for the profile default, or 12–24 digits for deliberate form-boundary QA.
digits
{{ params.mask_last }}
Mask the preview only; raw copy and machine exports retain the synthetic number.
Auto uses four digits for American Express and three for other profiles.
Expiry offsets are calculated from this explicit month so a shared fixture is reproducible.
Use 1–120 whole months ahead.
months
Use 1–120 whole months ahead and keep this at or above the minimum.
months
When on, a mismatched custom prefix falls back to the selected practical profile.
{{ params.enforce_prefix ? 'On' : 'Off' }}
Rejects a request when the selected prefix and length cannot supply enough distinct bodies.
{{ params.unique_batch ? 'On' : 'Off' }}
The same seed and settings reproduce the same generated rows.
{{ tableStatus }}
Generated synthetic card rows
#Card shapeNumberPrefixDigitsLuhnCVV / CVCExpiryCopy
Correct the settings to restore generated rows.
{{ row.index }}{{ row.network }}{{ row.display }}{{ row.prefix }}{{ row.length }}{{ row.luhn_valid ? 'Valid' : 'Invalid' }}{{ row.cvv || '—' }}{{ row.expiry || '—' }}
{{ liveStatus }}
{{ chartStatus }}
{{ tableStatus }}
Generation settings and interpretation
SettingValueQA meaningCopy
{{ row.label }}{{ row.value }}{{ row.note }}

Checkout forms need card-shaped test data long before a payment processor is involved. Length checks, pasted separators, masking, security-code fields, and expiry inputs can all fail inside the interface itself. Synthetic numbers let those paths be tested without copying a customer’s Primary Account Number (PAN) into a fixture, screenshot, or bug report.

A PAN has a recognizable structure. Its leading digits form the Issuer Identification Number (IIN), still often called a BIN. The middle is an account-identifying body, and the final digit is a Luhn check digit. Passing that checksum catches many typing errors, but it says nothing about whether an account exists, a card was issued, or a processor will accept the number.

Parts of a payment card number and their testing use
Part What it controls in form testing What it cannot prove
IIN or BIN prefixNetwork-shaped branching, grouping, and expected lengthIssuer identity or account ownership
Account bodyField capacity, uniqueness, masking, and fixture varietyA usable payment credential
Luhn check digitWhether the completed digit string satisfies the checksumAuthorization, balance, fraud status, or processor behavior

Realistic shape is useful for front-end quality assurance, but processor scenarios need provider-published test values or tokens. Approval, decline, 3-D Secure, refund, dispute, and webhook flows depend on the sandbox provider, not on a generated Luhn-valid number.

Treat every generated row as visible test data. A synthetic value may still resemble a live PAN, and masking only changes what is shown in the preview. The complete generated number remains available to copy and export, so keep these rows in test systems and never replace a seed or prefix with customer information.

How to Use This Tool:

Choose the form branch you need to exercise, then make the fixture reproducible before sharing it with another tester.

  1. Select a QA profile or choose a Card shape, then set Quantity. The profile supplies practical defaults, but it does not create an official processor scenario.
  2. Enter a Custom BIN / IIN only when a known synthetic prefix is part of the test. With Enforce profile prefix on, a prefix that does not overlap the selected card shape is replaced and reported as a warning.
  3. Choose the visible grouping and optional synthetic CVV/CVC or expiry fields. Use Length override only for deliberate boundary testing; zero keeps the selected profile’s default length.
  4. Set a Replay seed from 1 to 64 characters. Reuse that seed with every other setting to reproduce the same rows.
  5. Generate the batch and check the Luhn count, prefix strategy, and target length before copying a number into a local test.

Interpreting Results:

A complete batch should report every row as Luhn-valid. The card-shape label describes the practical prefix and default-length profile used for generation; it is not an issuer lookup. If the prefix strategy says that a bundled profile fallback was used, the custom prefix was not applied.

  • Compare Target length with the field branch you intended to test.
  • Keep the replay seed and settings together when a bug must be reproduced.
  • Use the displayed masking only for presentation checks. Copy and machine exports retain the complete synthetic number.
  • Switch to provider-published test cards or tokens before testing processor outcomes.

Technical Details:

A generated row is assembled from a selected prefix, a seeded sequence of body digits, and one checksum digit. The pseudo-random sequence is deterministic rather than cryptographically secure: the same seed, row number, and settings produce the same fixture.

Formula Core

The Luhn check digit is the value that makes the transformed digit sum divisible by 10. Starting at the rightmost digit of the unfinished number, every other digit is doubled; products above 9 are reduced by 9.

c=(10(Smod10))mod10

Here, S is the sum after alternating digits are transformed and c is the appended check digit. Validation repeats the alternating transformation over the complete number; a remainder of zero means the number passes Luhn.

Rule Core

  1. Choose a custom prefix when it is allowed by the selected profile, otherwise choose one value from the profile’s bundled prefix ranges.
  2. Fill the remaining body positions from the seeded sequence, leaving one final position for the check digit.
  3. Append the Luhn digit and reject a duplicate when unique-batch mode is on.
  4. Derive optional CVV/CVC digits and an inclusive whole-month expiry offset from the same seeded row sequence.
  5. Apply grouping and preview masking after the raw number has been created.
Bundled practical card-shape profiles
Card shapeBundled leading valuesDefault digits
Visa-shaped416
American Express-shaped34 or 3715
Mastercard-shaped51 to 55 or 2221 to 272016
Discover-shaped6011, 622126 to 622925, 644 to 649, or 6516
Diners Club-shaped300 to 305, 36, or 38 to 3914
JCB-shaped3528 to 358916
Maestro-shaped50 or 56 to 6916
UnionPay-shaped6216

These profiles are practical and intentionally non-exhaustive. They control fixture shape only and can become outdated as payment numbering ranges change.

Important generation limits
SettingAccepted ruleWhy it matters
Quantity1 to 100 rowsA unique request is rejected when the remaining body space is too small.
Length override0, or 12 to 24 digitsThe prefix must still leave room for one Luhn digit.
Custom prefixDigits only, at most 23 digitsProfile enforcement may replace a non-overlapping prefix.
Expiry window1 to 120 months ahead, inclusiveThe latest offset must be at least the earliest.
Replay seed1 to 64 charactersEvery setting, not the seed alone, must match for identical rows.

Responsible Use:

Use these values only for local form QA, fixtures, demonstrations, and screenshots. Do not submit them to live payment endpoints, represent them as official sandbox cards, or use a real PAN, customer identifier, or production BIN as input.

  • Luhn validity is a format check, not evidence of issuance or authorization.
  • Generated CVV/CVC and expiry values have no processor meaning.
  • A masked preview does not redact copied or exported rows.
  • Provider-specific behavior must be tested with that provider’s documented test data.

Worked Examples:

Repeatable checkout fixture

A Visa-shaped 16-digit batch with prefix 411111 and seed golden-visa can be kept beside a form test. Reusing the same quantity and every advanced setting recreates the same rows, while changing only the display format alters grouping rather than the underlying digits.

Prefix mismatch

If an American Express-shaped profile is paired with a custom prefix that does not overlap 34 or 37 while profile enforcement is on, generation uses a bundled profile prefix instead. The prefix warning is the cue to correct the test setup before copying the row.

References: