Library · Payment orchestration · Guide
Clear-PAN retry — claim map
GuideClear-PAN retry — claim mapBack to article
A vaulted token sometimes needs a new card entry. That is not account updater. Filter the claim before you spray the token.
| Claim | Reality | Get in writing | Do not |
|---|---|---|---|
| The vaulted token always retries forever | Some declines mark the credential non-reusable — silent posts will keep failing | Which families on this gateway force a new card entry vs token retry | Spray the same token until the window burns |
| Clear-PAN retry is the same as account updater | No. Updater refreshes the token from the network. Clear-PAN is a new card entry | N/A — different jobs; enroll updater separately | Wait on updater when the gateway already said re-enter card |
| CS can pull clear PAN from CRM notes | Most vaults never store clear PAN. Token-only means ask the shopper | Whether any PCI-scoped key-in path exists here — usually it does not | Invent digits from a last-four or a ticket note |
| Clear-PAN retry fixes soft NSF | No. NSF is money. Re-keying the same empty account does not create funds | N/A — wrong tool for NSF | Ask for a new card entry to “fix” insufficient funds |
| After clear-PAN, keep the old MIT chain | New card entry is a new original — later rebills must point at that sale | How this gateway stores the new original ID after a keyed card | Bill the old MIT token as if the PAN never changed |
| Hard fail → clear-PAN on a spare MID | No. Hard fails kill the token. Hopping buys chargebacks | N/A — stop; ask a new card on a clean path if the shopper is still there | Open a spare MID to force a dead credential |
Filter the claim. Clear-PAN means a new card entry when the vault path is dead. Account updater is a network file on the token. Soft NSF stays on the money calendar. Hard fails stop — do not hop.
Pairing procedure: When a vaulted token needs a clear-PAN retry. Topic: Orchestration.
Work with us — We run this job on your accounts. Services