Library · Payment orchestration · How to run this
When a vaulted token needs a clear-PAN retry
A clear-PAN retry is when a vaulted token path fails and the next honest move is a new card entry — not another silent token post. Network account updater can refresh PAN or expiry on the token without the shopper. Clear-PAN is the opposite shape: the shopper (or a scoped key-in) types digits again. Mixing the two invents a “retry” that never runs.
Pair: Clear-PAN retry — claim map on Orchestration. Soft vs hard next action: decline code playbook. Written soft-retry headroom: retry window.
When clear PAN is the path
Token dead / not reusable. Gateway or issuer says the vault credential cannot bill again. Kill the silent retry loop. Ask for a new card entry as a shopper-present sale when the shopper is there.
Scheme or gateway requires a new card present for this path. Some migrations, wallet rebuilds, or issuer flags will not accept the old token. That is a process rule — get it from this gateway, not a blog.
Updater already returned nothing useful. Expired wait is updater’s job first. If the file stays empty and the card is still soft-alive, clear-PAN from the shopper is the recover path — not spraying the dead token.
What not to do
Do not treat clear-PAN as updater enrollment math. Do not invent clear PAN from CRM notes you never stored. Do not re-key NSF hoping for cash. Do not hop a hard-fail token onto a spare MID and call it a clear-PAN fix. After a new card entry, point later rebills at that original sale — do not keep billing the old MIT chain as if nothing changed. See rebill original ID.
What to get in writing
Which decline families on this gateway force a new card entry vs silent token retry. Whether a CS key-in counts as shopper-present for the MIT chain here. What the vault returns when the token is non-reusable.
Related: Orchestration, account updater, dunning by family, vault token migration.
Procedure
- Name whether the gateway marked the token non-reusable.
- If updater applies, wait on that file first for expiry / replaced PAN.
- Ask the shopper for a new card entry when the vault path is dead.
- Point later rebills at the new original sale. Do not hop hard fails.
Failure modes
- Treating clear-PAN as account updater enrollment.
- Inventing clear PAN from CRM notes you never stored.
- Re-keying NSF hoping for cash.
- Hopping a hard-fail token onto a spare MID.
- Keeping the old MIT chain after a new card entry.
Worked example
None on this page yet. When one lands it will be a real case: what broke, the number, and what changed. Not a composite.
Glossary
- Clear-PAN retry
- A new card entry when the vaulted token path cannot bill again. Distinct from network account updater refreshing the same token.
Work with us — We run this job on your accounts. Services
FAQ
- Is a clear-PAN retry the same as account updater?
- No. Updater refreshes the vaulted token from the network. Clear-PAN retry means the shopper (or a PCI-scoped key-in) types the card again.
- Can CS pull the clear PAN from the CRM and retry?
- Only if you still hold clear PAN under PCI scope — most vaults do not. Token-only means ask the shopper.
- Does clear-PAN retry fix NSF?
- No. NSF is money. Re-keying the same empty account does not create funds.