| # | Number | Verdict | Issuer | Checksum | Len | Rule trace | Copy |
|---|---|---|---|---|---|---|---|
| {{ record.index }} | {{ record.formatted }} | {{ record.verdict }} | {{ record.issuer }} | {{ record.luhnValid ? 'Pass' : 'Fail' }} | {{ record.length }} | {{ record.primaryNote }} |
| Number | {{ focusRecord.formatted }} |
|---|---|
| Verdict | {{ focusRecord.verdict }} |
| Issuer | {{ focusRecord.issuer }} |
| MII | {{ focusRecord.mii }} |
| IIN-6 | {{ focusRecord.iin6 }} |
| IIN-8 | {{ focusRecord.iin8 }} |
| Length | {{ focusRecord.length }} |
| Expected lengths | {{ focusRecord.expectedLengthText }} |
| Summary note | {{ focusRecord.primaryNote }} |
| Rule | Status | Detail |
|---|---|---|
| {{ trace.rule }} | {{ trace.status }} | {{ trace.detail }} |
A payment card number, formally called a Primary Account Number or PAN, is a structured identifier rather than a random string. The opening digits point to an issuer range, the overall length usually follows family rules, and the final checksum digit is there to catch common transcription mistakes before a payment system ever sees the number. This validator reads that visible structure and turns it into a practical local check.
The tool evaluates one pasted entry by default and labels it Pass, Review, or Fail. If you switch on Batch mode, the same logic expands to a list so you can review a clipboard dump, a QA file, or an exported note set without sending the data to a server.
That makes it useful in the quiet cleanup work that surrounds real payment systems. Support notes often contain one mistyped digit. Test-card lists often mix valid and broken samples. CSV exports can carry duplicates, short fragments, or formatting debris. The page is built for exactly those situations: it strips spaces and punctuation inside each entry, checks the resulting digits, and then shows both row-level detail and batch-level patterns.
The current package also keeps the review flow intentionally visible. Validation Snapshot highlights the focused record, Validation Log lists every processed row, the chart tabs summarize verdicts, issuers, and lengths, and Rule Trace explains why the focused row landed where it did. When a batch contains a problem row, the summary shifts to that first non-passing record so the issue surfaces immediately instead of hiding behind the aggregate counts.
The most important boundary is simple: a structural pass is not an authorization result. A number can satisfy the checksum and still be unusable, expired, synthetic, blocked, or unrelated to the issuer family you expected. Everything runs in the browser and there is no server-side helper for the validation flow, but full PANs should still be treated as sensitive data and replaced with test or scrubbed values whenever possible.
The default single-entry behavior is deliberate. If you paste several lines while Batch mode is off, the tool processes only the first parsed number and raises the inline warning that extra lines were ignored. That is a good safety rail for quick spot checks, because it prevents a messy note from silently becoming a full batch analysis when you only meant to verify one value.
When you do want the full list, switch Batch mode on first. At that point the validator keeps every parsed entry that survives the minimum-digit filter, and Remove duplicates becomes available so repeated rows can collapse into one record. The parser expects one number per line or comma- or semicolon-separated entry. Spaces and dashes inside a number are fine because they are stripped before validation, but spaces by themselves are not treated as record separators.
Issuer-aware length check is the setting that turns a simple checksum pass into a more nuanced screening step. Leave it on when you want checksum-valid but suspicious issuer-and-length combinations to surface as Review. Use it as a second-pass filter after the checksum, not as a replacement for the checksum itself.
The main working view is Validation Log. It shows the normalized number, verdict, detected issuer, checksum result, length, and the short note that summarizes why the row landed there. The chart tabs are better for pattern recognition than for final decisions. Decision Mix tells you whether the batch is mostly clean or mostly broken. Issuer Mix shows whether the list clusters around one family. Length Profile quickly reveals clipped exports or mixed-format input.
Rule Trace is where individual exceptions become easier to understand. You can choose a different focused record there, but the default focus is already useful because the tool prefers the first non-passing row when one exists. That means a failing checksum or a review-worthy issuer mismatch rises to the top without any manual sorting.
The package follows a strict local sequence. It first splits the raw text into candidate entries, trims empty fragments, removes all non-digit characters from each candidate, applies the minimum-digit filter, optionally removes duplicates in batch mode, and only then runs the card checks. That order matters because it keeps formatting cleanup separate from actual validation logic.
After normalization, the validator tests three structural ideas: whether the digit count stays in the broad 12 to 19 range, whether the number passes the Luhn checksum, and whether the prefix matches one of the shipped issuer profiles. It also reports three identifier slices for each row: the Major Industry Identifier from the first digit, IIN-6 from the first six digits, and IIN-8 from the first eight digits. Showing both issuer slices is useful because six-digit BIN language is still common in operations, while modern issuer identification has expanded to eight digits.
Read pasted text or one imported .txt or .csv file, split entries by line, comma, or semicolon, then strip non-digit characters inside each entry.
Test broad length range, run the Luhn checksum, detect the issuer family from built-in prefix rules, and compare length to the detected family when issuer-aware length review is enabled.
Return Pass, Review, or Fail, then expose the same record set through the log table, charts, rule trace, JSON payload, and exports.
| Issuer label | Built-in prefix rule | Expected lengths |
|---|---|---|
| Visa | Starts with 4 |
13, 16, 19 |
| Mastercard | 51-55 or 2221-2720 |
16 |
| American Express | 34 or 37 |
15 |
| Diner's Club | 300-305, 36, 38, or 39 |
14 |
| Discover | 6011, 65, 644-649, or 622126-622925 |
16, 19 |
| JCB | 3528-3589 |
16, 17, 18, 19 |
| UnionPay | Starts with 62 |
16, 17, 18, 19 |
| Maestro | Starts with 50, 56, 57, 58, 63, or 67 |
12 to 19 |
| Unknown | No shipped prefix rule matched | No family-specific length comparison |
The table above describes the shipped matcher, not a complete network routing database. That is why the validator is best used as a structural screening tool. It is intentionally useful for spotting likely mistakes and classifying familiar patterns, while still being conservative about anything outside the built-in prefixes.
| Verdict | What triggered it | How to read it |
|---|---|---|
Pass |
Length stays in the broad 12 to 19 range, checksum passes, and the built-in issuer rules do not raise an active concern. | The number is structurally plausible under the shipped checks. It is still not proof that the account is real or chargeable. |
Review |
Checksum passes but the issuer stays unknown, or issuer-aware length review is enabled and the length looks unusual for the detected family. | The number is not obviously broken, but it needs context before you trust it. This is the tool's caution state. |
Fail |
The digit count falls outside the broad 12 to 19 range or the Luhn checksum fails. | The number is structurally wrong for the validator's shipped rules and should be treated as a bad entry until corrected. |
One detail is worth calling out explicitly: turning off Issuer-aware length check only relaxes the issuer-length comparison. It does not convert an unknown issuer into a pass, and it never overrides a checksum failure.
| Field | Meaning here | Practical use |
|---|---|---|
| MII | Category label derived from the first digit | A quick first-pass industry hint before you look at the fuller issuer prefix. |
| IIN-6 | The first six digits of the normalized number | Useful when a system, note, or legacy process still talks in six-digit BIN terms. |
| IIN-8 | The first eight digits of the normalized number | Useful when the discussion has already moved to eight-digit issuer identification. |
.txt or .csv file.Batch mode off when you only want a quick check of the first parsed number. If the page warns that extra lines were ignored, either accept the single-entry result or switch batch mode on and let the whole list run.Minimum digits to drop short fragments from pasted notes or damaged exports before they reach the validation logic.Remove duplicates only when repeated rows are noise. If repeat frequency itself matters, keep duplicates in the batch.Issuer-aware length check on when you want checksum-valid but unusual issuer-length combinations to land in Review instead of blending into the passing rows.Validation Snapshot and Validation Log first. Then use Decision Mix, Issuer Mix, and Length Profile to understand batch shape.Rule Trace when a row needs explanation. Use the focus selector there to move from one record to another without changing the batch itself.The page recalculates as inputs and settings change, so there is no separate run button in the current flow. If the numbers are changing underneath you, treat that as a sign to finish the input cleanup first and only then review the verdicts.
A Pass means the number survived the validator's structural checks. It does not mean the card is active, billable, safe to store, or appropriate to use in live code. Read it as "format looks internally consistent," nothing more.
A Review result is often the most useful one in practice because it points to the gray area between obviously bad and confidently plausible. These rows are the ones that deserve manual context: maybe the number is a test credential from a family the built-in matcher does not recognize, maybe it is clipped to an unusual issuer length, or maybe the source document simply needs to be checked against the original.
A Fail is the straightforward cleanup state. Either the number is too short or too long for the validator's broad range, or the checksum breaks. In real datasets that usually means a mistyped digit, a missing digit, an accidental merge of two values, or a fragment left behind by copy-and-paste formatting.
The charts help you decide whether you are looking at one isolated bad row or a more systematic problem. If Decision Mix shows a high fail rate, the source data is probably noisy. If Issuer Mix is dominated by one family but the review count is high, the batch may be structurally close while still violating your expected issuer rules. If Length Profile collapses around one impossible or unexpected digit count, the issue is often export truncation rather than random typing.
Rule Trace is the best place to slow down before making a decision. It shows the exact rule statuses for the focused row and keeps the short summary note beside the structured trace. In a batch with problems, that trace is usually faster and more reliable than trying to infer the cause from the chart shapes alone.
A support ticket might contain one real test number followed by another value on the next line. With Batch mode off, the page processes the first parsed entry only and warns that later lines were ignored. That is useful when you want to confirm one number quickly without accidentally turning the whole note into a batch report.
Suppose a batch contains three familiar test numbers and one line with a broken checksum. Turn batch mode on, leave issuer-aware length review enabled, and let the list run. The snapshot will move to the failing row, the log table will show the checksum failure directly, and the charts will still tell you that most of the batch is structurally fine even though one row needs correction.
Sometimes a number passes the checksum but does not sit cleanly inside the shipped issuer rules. That is where Review matters. Instead of pretending the value is fully trustworthy, the validator surfaces it as a row that needs context. In practice, that is the right place for unfamiliar test credentials, edge-case issuer families, and clipped data that still happens to satisfy the checksum.
No. It means the digits look structurally consistent under the shipped rules. Authorization, account status, fraud controls, expiration, and live issuer decisions are outside the scope of this page.
Because the default mode is single-entry. When batch mode is off, the validator keeps only the first parsed number and warns you that additional lines were skipped.
Review is reserved for rows that still pass the checksum but need context, such as an unknown issuer or, when issuer-aware length review is enabled, a length that does not fit the detected issuer profile. Fail is used for broken checksum or obviously out-of-range length.
The current validation flow runs entirely in the browser and does not rely on a server-side helper. Imported files are read locally, and the same local record set powers the table, charts, and JSON output.
Because both still appear in real payment operations. Six-digit BIN language remains common in older systems and documentation, while eight-digit issuer identification is part of the more current standard landscape.
Prefer test numbers or scrubbed samples. Even though the page works locally, a full PAN is still payment-card data and deserves careful handling.