How Card Validation Works
Card validation checks a record against the rules of its format. This page explains what a structural check can prove, what an authorisation request is, and how to read the response code when one comes back.
By Daniel Cross, Senior Payment Systems Analyst · Last updated: 2026-10-20
Two different things people call validation
A structural check asks whether a card record is internally consistent: the right number of digits, a valid prefix, a check digit that matches, an expiry in the future, a security code of the right length. An authorisation asks the issuer whether a transaction would be approved. The first is arithmetic. The second is a request over the network. Conflating them is the most common source of bad tooling.
| Check | Question it answers |
|---|---|
| Prefix and length | Does the record match a known product format |
| Luhn check digit | Is the number internally consistent |
| Expiry date | Is the record inside its validity window |
| Security code length | Does the code match the brand's format |
| Authorisation response | Would the issuer approve a transaction |
What a structural check cannot tell you
A structural check proves the record is well formed. It says nothing about whether the account exists, whether it is blocked, whether it has funds, or whether it has been reported. A number can be perfectly valid, pass the Luhn check and still be worthless. This is why the free validators on this site are described as format tools and not as a way to establish that a card works.
- No contact is made with an issuer
- No account existence is confirmed
- No balance or status is checked
- The output is a format verdict, not a usability verdict
What an authorisation request is
In a normal card-not-present transaction the merchant sends the card number, expiry, security code and an order amount to the acquirer, which routes it to the issuer. The issuer applies its own risk rules and returns an approval or a decline with a response code. That exchange is a live financial transaction and it is not something a reference tool should perform.
- The acquirer routes the request to the issuer
- The issuer applies its own risk policy
- The response code explains why a request was declined
- The request is a real financial transaction
Reading a response code
Issuers return standardised response codes. An approval means the transaction was authorised. A soft decline can mean a temporary block, a velocity limit or a mismatch in billing data. A hard decline usually means the account is closed, blocked or expired. Reading the code correctly avoids discarding records that are still perfectly usable.
- Approval: the transaction was authorised
- Soft decline: retryable, often temporary
- Hard decline: closed, blocked or expired
- Do not treat a decline as a permanent verdict without the code
Why the data behind a check decays
A check result is a snapshot. Issuer rules change, accounts are closed and reported, and prefixes are reassigned between issuers. Any tooling that records a result should record when it was made, because a check from last week and a check from an hour ago are not the same claim. Every page in the BIN dataset on this site carries a last-updated date for exactly this reason.
- Issuer risk rules change over time
- Accounts are closed, blocked and reported
- Prefixes are reassigned between issuers
- Always record the timestamp alongside the result
Frequently Asked Questions
What is card validation?
Checking that a card record is internally consistent: a known prefix, the right length, a matching Luhn check digit, an expiry in the future and a security code of the right length. It is a format check, not a transaction.
What is the difference between validation and authorisation?
Validation is arithmetic performed locally against the record. Authorisation is a request to the issuer over the network that asks whether a transaction would be approved. Only the second involves the issuer.
Does a passing Luhn check mean the card works?
No. The Luhn check only proves the number is internally consistent. It says nothing about whether the account exists, is blocked, has funds or has been reported.
Why does a check result need a timestamp?
Because the result decays. Issuer rules change, accounts are closed and prefixes are reassigned, so a check from last week is a weaker claim than one from an hour ago.
What is a response code?
A standardised code returned by the issuer with an approval or decline. It distinguishes a temporary problem such as a velocity limit from a permanent one such as a closed account.