KEY TAKEAWAYS
- Dead is terminal for the card number in almost all cases.
- Gateway mapping differences mean some "dead" results deserve a second opinion.
- Unknown is the retryable state, not dead.
- Suppress dead cards permanently; never pay to recheck them.
- Live means active now — a snapshot, not a guarantee for a future charge.
- Unknown deserves one fallback pass, not infinite retries.
A dead result says the issuer rejected the verification cleanly — closed account, reported lost or stolen, or invalid number. Those are terminal states, with one nuance worth understanding.
Terminal states
Closed accounts do not reopen under the same card number. Lost, stolen and pickup statuses block the card permanently. Invalid numbers never become valid. For practical list hygiene, dead is final.
The nuance: misclassification
Gateways map issuer responses differently. A response one gateway calls dead may be classified unknown elsewhere — especially "do not honour" responses that reflect risk rules rather than account closure. If a card matters commercially, corroborate on a second gateway before treating it as permanently dead.
What can change
Unknown can become live or dead later: challenges expire, risk rules change, funding arrives. That is why unknown results are retryable while dead results are not.
Practical policy
Move dead cards to a suppressed list permanently. Re-test unknowns on a second gateway or after 24 hours. Never recheck dead cards in every run — it costs balance for a foregone conclusion.
A dead result is final for the present state of the account: the issuer said the card is closed, blocked, reported lost or otherwise not chargeable. What can change over time is the account itself. Banks reopen accounts, replace lost cards with new numbers on the same account, and reverse fraud blocks after review — but in each case the card number usually changes, so the old dead number stays dead.
The practical rule follows from that: do not re-run dead cards in the same campaign; do process the account through your normal recovery channels, because the customer may return with a different card that a future check will classify as live.
Key points about dead-card revival
- Dead means the number is not chargeable now — treat it as conclusive for the run.
- A reopened account typically arrives with a new card number, so re-check the new number, not the old one.
- Never retry dead cards automatically; the answer will not change and the balance will drop.
- Move dead cards into recovery flows rather than silently discarding the customer.
Interpreting outcomes in dead-card revival
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. The honest reading of unknown is "no answer yet". The card is neither good nor bad, and the remedy is a different route, not a repeat of the same one. Two metrics describe any run: how many cards classify, and how long the pass takes. Everything else is commentary. It is a small rule that changes how dead-card revival behaves at scale.
Dead-card revival in practice: a repeatable path
Deduplicate before submitting: the same card in a list twice is billed twice if both copies classify. Validate checksums and expiry dates before any paid request; the free browser tools exist precisely so malformed rows never reach a provider. Keep a small balance buffer so an interrupted run never leaves a half-classified list and the temptation to re-check everything. Treat every large list as two lists: the part that classifies on the first pass, and the remainder that needs a decision about how hard to chase. Remember it the next time dead-card revival produces an ambiguous answer.
Limits and responsible use of dead-card revival
A check does not move money, does not create a charge and does not touch the cardholder's credit file. When a proposed use cannot be explained to a compliance reviewer in one sentence, it is probably not a fit. The platform does not trade card data, and nothing in the system is designed to bypass a cardholder's consent. In dead-card revival work, that is the difference between a signal and a guess.
How dead-card revival actually works
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. The four outcomes are categorical rather than numeric because decisions are categorical too: proceed, recover, retry or log. Rate limits, formats and latency all come from the provider side, which is why per-gateway configuration exists instead of one global setting. It sounds obvious until a real run tests it.
Benchmarks and distribution for dead-card revival
The reference BIN table covers hundreds of thousands of issuer ranges, and it is deliberately separate from account-status data: one describes issuers, the other describes cards. Latency percentiles matter more than averages: the p90 and p99 tell you what a slow run actually feels like. Aggregate numbers describe populations, not individual cards. Use them to size timeouts and retry budgets, never to judge one account. When the classified rate moves, the cause is usually a route or provider change rather than the underlying cards. That distinction is what keeps dead-card revival decisions clean.
Running dead-card revival as a process
Alert on classified-rate drops, not just on errors; silent degradation is the expensive kind. Document the route, the batch policy and the retry rules next to each production run; six months later that note is the diagnosis. Reconcile spend monthly against classified results; the difference between the two numbers is where retries hide. Keep one primary gateway and one fallback, and switch on evidence — error spikes and classified-rate drops — rather than on price alone. Holding that line is what makes dead-card revival reliable over time.
Pitfalls that cost money in dead-card revival
Comparing dead-card revival routes on list price instead of classified rate hides the real economics. Treating a dead-card revival snapshot as permanent truth overstates what verification can promise. Defining result handling after the run in dead-card revival produces spreadsheets instead of decisions.
- Skipping format validation before dead-card revival turns simple input mistakes into provider rejects that look like card problems.
- Letting duplicates through the input during dead-card revival pays twice for the same answer.
- Using BIN reference data as account status in dead-card revival confuses two different questions and produces confident, wrong decisions.
- Scheduling dead-card revival after the decision it informs removes most of its value.