KEY TAKEAWAYS
- The BIN identifies the issuer; Luhn validates the number format.
- Authorization reserves funds; verification reports status.
- Unknown is not dead — handle it separately.
- Holds are released when a check does not classify.
- Live means active now — a snapshot, not a guarantee for a future charge.
- Generated test numbers are checksum-valid and never chargeable.
Short, practical definitions for the terms you will meet while verifying and processing cards.
A–C
- Acquirer: the bank that processes payments on behalf of a merchant.
- Authorization: a request to reserve funds on a card for a specific amount.
- AVS (Address Verification System): matches the billing address supplied with a card to the address on file at the issuer.
- BIN/IIN: the first digits of a card number identifying the issuing institution. See BIN lookup explained.
- Capture: converting an authorization into an actual charge.
- CVV/CVC: the security code printed on the card, used to prove physical possession.
D–I
- Decline: the issuer refused the transaction; the reason is given as a code. See decline codes explained.
- Dunning: the process of recovering failed subscription payments with retries and customer prompts.
- Hold: a temporary reservation of funds; released if the check does not complete.
- Issuer: the bank or institution that issued the card and answers authorization requests.
L–S
- Luhn algorithm: a checksum that catches most mistyped card numbers; it validates format, not status.
- Prepaid balance: funds deposited in advance and spent per check — how checking is billed here.
- Settlement: the final transfer of funds after capture; holds become real charges.
- 3-D Secure: an authentication step where the cardholder confirms a transaction with their bank.
T–Z
- Tokenization: replacing card data with a reference token so the original number need not be stored.
- Unknown: a check outcome where the issuer did not give a definitive answer. See result states.
- Velocity limit: a cap on how many transactions an account may make in a period.
- Verification: confirming card status without moving money. See verification vs authorization.
Missing a term? The FAQ covers platform-specific questions.
This glossary collects the vocabulary of card verification as the platform uses it, organized by layer: reference terms about issuers, transaction terms about money movement, and result terms about checks. Keeping the layers distinct prevents the most common category errors in operations and documentation.
Each entry links to its full explanation, and the result terms — live, dead, unknown, error — are the ones to internalize first, because every workflow decision ultimately routes on them.
How the verification vocabulary actually works
The four outcomes are categorical rather than numeric because decisions are categorical too: proceed, recover, retry or log. Nothing in the check moves money: the request asks a question, the issuer answers, and the platform records one of four outcomes against your account. The platform keeps one history row per request with status, cost and before/after balance, which makes the whole loop auditable at the individual check level. Error means the check itself failed technically: a timeout, a provider fault or malformed input. No classification was produced, and no charge applies. It is a small rule that changes how the verification vocabulary behaves at scale.
A check sends an authorization-shaped request through a provider to the issuer and classifies the reply into one of four states: live, dead, unknown or error. Live means the issuer answered and the account is active and chargeable at that moment; it is strong evidence, not a promise about a future charge. Unknown means no definitive answer was received — often an issuer challenge or soft decline — so the card remains unclassified and deserves at most one fallback pass. Keep it in mind whenever the verification vocabulary results are reviewed.
Running the verification vocabulary well: the operating steps
Start with a pilot of fifty cards. It surfaces format mismatches and routing surprises while the cost of being wrong is still measured in cents. Deduplicate before submitting: the same card in a list twice is billed twice if both copies classify. Log request identifiers and outcomes, never full card numbers. Debugging rarely needs a PAN, and storing one is a liability. Validate checksums and expiry dates before any paid request; the free browser tools exist precisely so malformed rows never reach a provider. It is a small rule that changes how the verification vocabulary behaves at scale.
Interpreting outcomes in the verification vocabulary
A live answer is evidence about the account, not a guarantee about a specific future transaction; issuer rules can change between the check and the charge. A result is only as fresh as its timestamp. High-value decisions should use checks that ran close to the moment of the decision. Classified rate is the share of cards that produce a definitive answer; it is the first number to compare when switching gateways. Two metrics describe any run: how many cards classify, and how long the pass takes. Everything else is commentary. That single habit separates routine the verification vocabulary from expensive the verification vocabulary.
Keeping the verification vocabulary predictable
Treat provider outages as routing problems: switch routes, recover the unclassified remainder, keep the answers you already paid for. Reconcile spend monthly against classified results; the difference between the two numbers is where retries hide. Document the route, the batch policy and the retry rules next to each production run; six months later that note is the diagnosis. A written triage table — one action per result class — keeps large runs mechanical and auditable. Remember it the next time the verification vocabulary produces an ambiguous answer.
Boundaries of the verification vocabulary
When a proposed use cannot be explained to a compliance reviewer in one sentence, it is probably not a fit. Operators remain responsible for the legal basis on which they hold and process card data. Verification is at its best when it is boring: a routine status step inside an existing, authorised process. That distinction is what keeps the verification vocabulary decisions clean.
Funding and costs around the verification vocabulary
A small buffer in the balance buys continuity; running to zero mid-list buys a mess. History records cost and before/after balance for every check, making spend auditable at the individual row. A deposit address is generated per invoice, and confirmation progress is visible in real time on the deposit page. The real cost metric is cost per classified card, because it folds in retries and unknown rates. That distinction is what keeps the verification vocabulary decisions clean.
Handling keys and data in the verification vocabulary
Log identifiers and outcomes, not card numbers. Debugging almost never requires a PAN. Encrypted transport and account-scoped access are defaults; nothing about the integration requires changing them. API keys are server-side secrets: they belong in environment configuration, never in URLs, logs or client bundles. The dashboard shows the key once and lets you rotate it at will; rotation is cheap, leaks are not. The habit costs nothing and removes a recurring class of mistakes.
Measured behaviour of the verification vocabulary
Cost per classified card is the honest metric. A cheap-per-request route with a high failure rate is the most expensive option in practice. The platform publishes outcome distributions and latency percentiles from real traffic, refreshed monthly, precisely so expectations can be calibrated against reality. Sample sizes matter. Small windows produce noisy percentages, which is why published aggregates carry minimum thresholds. Trends beat snapshots: a classified rate that drifts over weeks says more than any single run's result. Keep it in mind whenever the verification vocabulary results are reviewed.