When a checkout form receives a card number, the first useful question is often not whether the payment will be approved.
It is whether the input is structurally plausible and which network rules should be shown to the user.
The open-source package provides that small client-side or server-side building block.
It detects 11 brands, removes spaces and hyphens, and applies a Luhn checksum.
It has zero runtime dependencies and exposes CommonJS functions for validation and brand detection.
This tutorial builds a minimal Node.js check, verifies the result with known test numbers, and explains what this kind of validation cannot tell you.
TL;DR Install version , call when you need both a boolean result and a brand, and call when you only need the network name.
The package does not contact a payment processor, authorize a transaction, tokenize data, or prove that a card exists.
Prerequisites You need: Node.js 12 or newer.
The package declares in its metadata. npm.
A terminal and a small JavaScript file.
The package is released under the MIT license.
The examples below target the published npm package version , which is also the version I installed for this walkthrough.
Install the package Create a directory for the example and install the pinned version: Pinning the version makes the example reproducible.
If you use a different version later, check its README and package metadata before copying the behavior into a production application.
Build the smallest useful check Create : Run it: The expected output is: The Portuguese property name is part of the package's public return shape.
Keep it as-is when consuming the API, or map it to an application-specific name at your boundary.
Understand the two API paths returns an object with and .
It first strips non-digit characters, rejects values shorter than 13 or longer than 19 digits, detects a brand from configured prefixes, and then runs the Luhn calculation. returns a brand name or . is an alias for the same function.
This is useful when the UI needs to change an icon or helper message before the complete number is validated.
The implementation checks more specific ranges before broad ones.
That matters for Brazilian brands such as Elo, whose configured prefixes can begin with , the same first digit used by Visa.
A broad prefix check performed first could classify a supported Elo example as Visa.
Add an explicit application boundary The package accepts a string and normalizes it internally, but your application should decide how to handle empty input, pasted content, and form errors.
A small wrapper can keep the package's output separate from UI messages: This wrapper deliberately reports a checksum failure as an input problem.
It does not imply that a valid checksum means the card can be charged.
Reproduce the verification The repository README documents these public examples.
You can check the package independently with a one-line Node command: The verified result is: For an application test suite, add cases for formatting normalization, unknown prefixes, too-short values, each supported network you rely on, and known invalid checksums.
Do not use real customer card numbers in tests or fixtures.
Why the check works Brand detection is prefix matching against the rules in the package source.
Luhn validation is a checksum calculation that doubles alternating digits from the right, subtracts nine when a doubled value exceeds nine, and checks whether the total is divisible by ten.
That division of responsibility is useful: prefix rules answer “which configured network might this resemble?” while Luhn answers “does this string satisfy the checksum?” Neither step performs authorization or a network lookup.
Failure modes and security boundaries There are several important limitations: A valid Luhn result does not prove that a card is issued, active, funded, or owned by the person entering it.
Prefix tables can become outdated as networks change ranges.
Review the package source and release hi