{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

Issuer{{ resultsReady ? focusRecord.issuer : '—' }} Luhn{{ resultsReady ? (focusRecord.luhn_valid ? 'Pass' : 'Fail') : '—' }} Processed{{ resultsReady ? computation.values.processed_count : '—' }}
Paste one value, or enable batch mode for newline, comma, or semicolon-separated test values.
Drop TXT or CSV onto the textarea. Input stays out of the page URL.
{{ batch_mode ? 'On' : 'Off' }}
Off validates the first usable candidate and reports how many additional values were ignored.
{{ issuer_length_check ? 'On' : 'Off' }}
Built-in family patterns are heuristics for test data, not live issuer-routing evidence.
digits
The default 12 removes last-four fragments while retaining the current product's card-like input boundary.

{{ ignoredMessage }}

{{ remove_duplicates ? 'On' : 'Off' }}
The neutral default is off. This setting has no effect while batch mode is off.
  • {{ row.label }}{{ row.status }}
    {{ row.detail }}

The chart renderer is unavailable. Exact counts remain available in the summary and validation log.

NumberVerdictIssuerLuhnLengthActionCopy
{{ row.number }}{{ row.verdict }}{{ row.issuer }}{{ row.luhn }}{{ row.length }}{{ row.action }}
Credit Card Number Generator Generate reproducible Luhn-valid card-shaped fixtures for form testing, with synthetic prefixes and optional CVV or expiry fields.
Credit Card Calculator Estimate credit card payoff time or solve a target payment from balance and APR, with new charges, lump sums and promotional-rate periods.
Payment Processor Fee Calculator Calculate processor fees or gross up a charge for a target deposit using cent rounding, editable rate rules and current provider comparisons.
APR Calculator Estimate APR from loan proceeds and finance charges across regular payment schedules, including a different final installment and note-rate comparison.

A payment-card number carries enough structure to catch many ordinary transcription mistakes before a value reaches a payment form or test suite. The full identifier is a Primary Account Number (PAN). Its leading digits describe an issuer-identification range, its middle portion identifies the account within that range, and its final digit completes a Luhn checksum.

Structural checks are useful for approved sandbox numbers, fixture lists, form testing, and cleanup of card-like values copied from documents. Spaces and hyphens can be ignored for the checksum, while a missing, repeated, or mistyped digit usually changes the result. The same check is far too weak to establish that an account exists or that a payment would be approved.

Evidence Useful conclusion Unsafe conclusion
12 to 19 digitsThe value fits the broad retained PAN length boundary.The length is valid for a particular issuer family.
Luhn passThe check digit balances after the alternating-digit transformation.The account is active, authorized, funded, or genuine.
Recognized prefixThe value resembles one of the built-in payment-family patterns.The current issuer, product, route, or acceptance policy is known.

Issuer Identification Number (IIN) is the standards term for the leading issuer-assignment digits; Bank Identification Number (BIN) remains common industry wording. Six- and eight-digit views may both appear in payment work, but a local prefix pattern is only a heuristic. Live routing and issuer decisions require current data from a payment brand, acquirer, processor, or another trusted source.

Full PANs are sensitive even when the task is only validation. Approved test numbers or masked samples are safer for screenshots, tickets, documentation, and shared fixtures. A local structural check does not remove obligations that apply to collecting, displaying, storing, or exporting real cardholder data.

The most consequential mistake is treating a green checksum as payment proof. Authorization also depends on the issuer, account state, expiry, security data, merchant context, fraud controls, and network response. Structural validation belongs before those checks, not in place of them.

How to Use This Tool:

Use non-production values whenever possible. Decide first whether you are checking one suspected typo or reviewing a list of test fixtures.

  1. Paste a value into Card number. Spaces and hyphens are allowed because non-digits are removed before validation.
  2. Turn on Batch mode for newline-, comma-, or semicolon-separated values. With batch mode off, only the first usable candidate is checked and later candidates are counted as ignored.
  3. Leave Issuer-aware length check on when family-length heuristics help your test review. Turn it off when only the broad length and Luhn checks matter.
  4. Set Minimum digits high enough to discard masked fragments or last-four values. In batch mode, enable duplicate removal only when repeated fixtures should be counted once.
  5. Read the first non-pass record in Focused review, then use the validation log to correct failed digits or investigate Review results.

Interpreting Results:

Fail means the retained number falls outside 12 to 19 digits or does not balance under Luhn. Review means the hard structural checks pass but the prefix is unknown or, when issuer-length review is enabled, the digit count is unusual for the matched family. Pass means only that the enabled structural checks align.

For a suspected transcription error, compare the normalized digits with the trusted source instead of changing a digit until Luhn passes. For test fixtures, confirm that the number comes from the payment provider's documented test set. Never use a verdict as evidence of authorization or cardholder identity.

Technical Details:

Luhn is a mod-10 check-digit method. Starting at the rightmost digit, keep that digit unchanged, double the next digit to its left, continue alternating, and subtract 9 from any doubled value above 9. A structurally valid sequence has a transformed sum divisible by 10.

Formula Core

Let di be a digit counted from the right, with the check digit at position 0. The transformation doubles odd positions and leaves even positions unchanged.

∑i=0n-1 T(di,i) mod10=0
T(d,i)= dwhen i is even 2dwhen i is odd and 2d ≤ 9 2d-9when i is odd and 2d > 9

For the approved Visa test value 4111 1111 1111 1111, the transformed digits sum to 30, and 30 mod 10 is 0. Changing the final digit to 2 raises the sum to 31, so the value fails.

Rule Core

Verdicts follow a fixed order. An earlier failure prevents a later heuristic from upgrading the result.

  1. Fail when the normalized value contains fewer than 12 or more than 19 digits.
  2. Otherwise fail when the Luhn sum is not divisible by 10.
  3. Otherwise review an unknown issuer family when issuer-length review is enabled.
  4. Otherwise review a recognized family whose digit count is outside that family's built-in lengths.
  5. With issuer-length review disabled, an unknown family still receives Review; known families that meet the hard checks receive Pass.

Built-in patterns cover Visa, Mastercard, American Express, Diner's Club, Discover, JCB, UnionPay, and Maestro. They are intentionally static test-data clues, not live issuer tables. The broad 12 to 19 digit boundary is also a local validation policy rather than a claim that every length is valid for every payment network.

Batch input is split at newlines, commas, and semicolons. Each candidate is reduced to digits, candidates shorter than the selected minimum are discarded, and optional deduplication compares the normalized digit strings. The selected minimum accepts whole numbers from 0 through 19; setting 12 is useful for filtering last-four fragments while retaining the current broad PAN boundary.

Privacy Notes:

The validation runs in the browser and does not contact an issuer or payment network. That local path reduces transmission, but it does not make a full PAN safe to paste, display, copy, export, or retain.

  • Prefer provider-published test numbers, synthetic fixtures, or masked values.
  • Avoid putting full PANs in screenshots, tickets, shared documents, analytics, or downloadable reports.
  • Follow your organization's approved cardholder-data process when real values are unavoidable.
  • Do not infer PCI DSS scope or compliance from browser-local processing alone.

Worked Examples:

A mixed fixture list

A batch containing 4111111111111111, 1234567812345670, and 4111111111111112 demonstrates all three verdicts. The first recognized Visa test number passes. The second balances under Luhn but has no built-in family match, so it needs Review. The third resembles Visa but its transformed sum is 31, so it fails and should be corrected from the trusted fixture source.

References: