Subscription product, renewals failing at a steady 3% a month with decline codes 54 (expired card) and 14 (invalid number). Our dunning job treated them like any other failure and emailed customers to update their card. Many never did, and we filed it under involuntary churn.
What we missed: when an issuer reissues a card, the PAN or expiry changes and the stored credential goes stale. Card networks run account updater services that push the new PAN and expiry to acquirers. Network tokens go further: the token stays the same and the scheme maps it to the new card, so nothing changes on your side. We were keeping raw PANs in the gateway vault with no updater enrolled.
After we moved stored credentials to network tokens, the share of renewals failing with 54/14 dropped from about 3% to well under 1%. What remained were genuinely closed accounts.
Two things worth checking in your own setup:
- Do you split declines by code before retrying? 54 and 14 will never succeed on a retry. 51 might.
- When token provisioning fails, does your vault silently fall back to the raw PAN, and do you log which credential type was used on each attempt?
Do you track renewal failures by credential type, or only by decline code?
Payneteasy handles this kind of payment flow for merchants and PSPs — see how it works.
Top comments (0)