Card number validator
Check a card number's Luhn checksum, length and brand, and see whether it is one of the published test numbers. Computed from the number itself — no BIN database, nothing stored, nothing logged. Use a test number.
Use a test number. Nothing is stored or logged, but a live card does not belong in any web form that is not your payment provider's.
One at a time is the demo. A list is the job.
Checking one value tells you about that value. The reason anyone does this at all is the other few thousand — last week’s signup export, the list you inherited, the file nobody has opened since. Paste or upload it and every row is scored: emails, phone numbers, IPs and domains mixed together, duplicates removed and counted first.
Check a whole list — free, no signup →Same check from your code
Card numbers are not part of the API, and deliberately so — the checksum needs no data from us. What the API scores at checkout is everything around the card: the email, the IP, the phone number and the domain, which is where card fraud shows up before the charge does.
curl "https://www.layercall.com/v1/score/user?email=buyer@example.com&ip=8.8.8.8" \ -H "X-Api-Key: YOUR_API_KEY"
1,000 lookups a month free, no card. Get a key or read the docs.
What each signal means
Luhn checksum
The mod-10 check digit every card number carries, computed over the whole number.
It catches almost every single-digit typo and every transposition of two adjacent digits. Validating it in your form saves a declined authorisation and the support ticket that follows.
Brand
Visa, Mastercard, Amex and the rest, from the IIN ranges the card networks publish.
Lets a form show the right logo and apply the right length rule before submission. Amex is 15 digits and everything else is mostly 16 — a form that assumes 16 rejects Amex outright.
Length
Checked against the lengths that brand actually issues, not a single global rule.
'A Visa is 13, 16 or 19 digits, this is 15' is a fixable message. 'Invalid card' is not, and it is why people abandon checkouts.
Test number
Whether the number is one of the published test PANs from the networks and processors.
A test number arriving at a live payment form almost always means an integration is pointed at the wrong environment. Occasionally it means somebody is probing what your form accepts. Both are worth an alert.
Questions
Is the card number stored or logged?
No. It is used to compute the answer and discarded — nothing is written to a log, a database or a cache, and the response only ever contains a masked form. The request is a POST rather than a GET for the same reason: a card number in a URL ends up in browser history, proxy logs and the next page's Referer header.
Should I paste a real card number here?
No, and you do not need to. Use one of the published test numbers — the checksum arithmetic is identical. A live card does not belong in any web form that is not your payment provider's, including this one.
Why no issuer name or bank country?
Those come from BIN databases that are scraped, resold and licensed on unclear terms, and they go stale quietly — a wrong issuer is worse than no issuer. Everything here is computed from the number itself using ranges the card networks publish, so there is no third-party dataset involved at all.
Does a valid checksum mean the card works?
No. It means the number is correctly formed. Whether the card exists, has funds, or has been reported stolen is known only to the issuer, and you find out through your payment provider at authorisation time.