Library · Payment orchestration · Guide
Token kill vs updater — claim map
GuideToken kill vs updater — claim mapBack to article
Hard-fail kill vs updater enrollment vs soft retry. Filter the claim. Distinct from clear-PAN, involuntary-churn rate, and updater-lift cash.
| Claim | Reality | Do | Do not |
|---|---|---|---|
| Every hard fail should hit account updater | No. Pick-up / lost-stolen / fraud kill the token | Kill stop-list shapes; enroll only expiry / account-change | Updater a dead stop-list card |
| NSF means kill the token or updater will fix it | No. NSF is money. Dunning calendar — not kill, not updater | Soft NSF on the family retry path | Enroll updater hoping for balance |
| Hop the killed token to a spare MID | No. Dead tokens stay dead. Hops buy chargebacks | Stop; ask shopper for a new instrument if needed | Cascade pick-up across backups |
| This map is clear-PAN retry | No. Clear-PAN is when the vault cannot retry and you may ask the shopper | N/A — open clear-pan-retry for that path | Confuse shopper re-entry with updater enrollment |
| This map is involuntary-churn rate | No. That page measures the hard-fail hole. This map is kill vs enroll | N/A — open involuntary-churn to type the rate | Skip measuring because you named the fork |
| Vendor recover % proves updater for every fail | No. Recover is after enrollment from your extract — and only for updater shapes | Your extract after enroll — updater-lift page | Invent a recover chip for kill codes |
Filter the claim. Kill stop-list and fraud tokens. Updater is for expiry / account-change shapes. NSF is dunning — not kill, not updater.
Pairing procedure: Kill the token or enroll updater — not both by habit. Topic: Orchestration.
Work with us — We run this job on your accounts. Services