The Card Number Nobody Should Store: Vladyslav Kolodistyi on Tokenisation and the Recurring Revenue Leak

A subscription business loses customers it never argued with. The card expires, the rebill fails, the retry fails, and a paying customer becomes a churn statistic without a single complaint. Nobody calls to cancel. The payments system cancels for them.
Mastercard research on recurring billing has put credential failure at roughly forty percent of involuntary subscription churn. That is not a marketing problem or a product problem. It is a payments problem, and tokenisation is the part of the payments stack built to solve it.
Vladyslav Kolodistyi, who works on payments infrastructure at PayAdmit, puts it in blunter terms.
“Most merchants think tokenisation is a security control,” says Vladyslav Kolodistyi. “Tokenisation is a revenue control that happens to improve security. Present tokenisation to a finance team as a compliance project and it never gets funded. Present it as recovered payments, and the conversation takes ten minutes.”
Why Network Tokenisation Moves Approval Rates, Not Just Risk Registers
The numbers are unusually clear for an industry that rarely publishes them. Visa reports that tokenised card-not-present payments see a 4.6 percent lift in authorisation rates globally compared with raw card numbers, alongside roughly a 30 percent reduction in online fraud, published in its own tokenisation knowledge hub. Mastercard puts its own average uplift at 2.1 percent.
Three mechanisms drive that. The card network validates the token before the authorisation reaches the issuer, a stronger signal than a bare card number. A per-transaction cryptogram proves the payment is legitimate. And network tokens update automatically when the underlying card is reissued, which is exactly the failure that kills card-on-file payments.
That third mechanism is the one Vladyslav Kolodistyi returns to most often. “Everyone quotes the fraud reduction because it sounds serious,” he says. “The money is in lifecycle management. Network tokens keep card-on-file credentials alive through reissuance. Without network tokens, every card replacement in your book is a coin flip on whether the next payment clears.”
Payments teams often confuse two different things called tokens, and the confusion is expensive. Gateway tokens, issued by a payment service provider, remove card data from merchant systems and reduce PCI scope. Useful, but they stay inside one provider’s environment. Network tokens are issued by the card scheme itself, travel across the payments ecosystem, and carry the assurance data that lifts approvals on card-not-present payments.
Vladyslav Kolodistyi treats the difference as strategic rather than technical. “A gateway token is a hostage,” he says. “It works beautifully until you want to change payments providers, and then you discover your entire card-on-file book lives in somebody else’s vault. Network tokens belong to the credential, not the vendor. Tokenisation is a procurement decision disguised as an engineering one.”
The lock-in point is easy to underestimate until a migration begins. A merchant with several million stored credentials and gateway-only tokenisation faces a choice between an expensive vault-to-vault transfer, a re-collection campaign that will visibly annoy customers, or staying put on unfavourable commercial terms. None of those outcomes are good, and all of them are avoidable at the design stage if network tokens are in the plan early.
For payments leaders weighing the work, five effects tend to justify a tokenisation programme on their own:
- Higher approval rates on card-not-present payments, in the range the card networks publish for network tokens
- Lower fraud rates on stored credentials than raw card numbers carry
- Automatic credential updates that keep card-on-file payments billing through card reissuance
- Reduced PCI DSS scope, because card numbers stop living inside merchant payments systems
- Portability across payment service providers, which preserves commercial leverage
The PCI angle deserves more attention than it gets. Reducing scope is not only an audit convenience. Every system that touches raw card numbers needs monitoring, access control and evidence. Tokenisation removes those systems from the perimeter entirely, and the operational saving compounds year after year across the payments estate, whether the merchant uses gateway tokens or network tokens.
What Card-on-File Payments Look Like When Tokenisation Is Done Properly
Vladyslav Kolodistyi is careful not to oversell the technology, and pushes back on figures circulating in the market.
“You see twenty percent uplift claims for tokenisation, and they are not honest,” he says. “The published network figures are the ones to plan against. What is true is that the gains concentrate in the problem segment. If your book is heavy on recurring card-on-file payments and aged credentials, recovery inside that segment is far larger than the blended average will ever show.”
That segmentation point changes how a business case should be written. Averaging tokenisation benefits across all payments understates the effect where it matters and makes the project look marginal. Modelling the aged card-on-file cohort separately usually produces a very different number, and a very different funding conversation.
Sequencing matters too. Tokenisation is not a switch. Existing card-on-file credentials have to be migrated into network tokens, new payments have to be tokenised at capture, and the retry and dunning logic has to be rewritten to account for credentials that now heal themselves. Retry schedules tuned for a world of dead cards will keep retrying payments that no longer need it.
According to Vladyslav Kolodistyi, the failure mode is predictable. “Teams enable network tokens, leave the old dunning cadence running, then wonder why the approval curve looks flat,” he says. “You have to retire the workarounds you built for the problem tokenisation just solved. Otherwise the programme pays for itself on paper and nowhere else.”
There is a regulatory tailwind as well. Under strong customer authentication regimes, tokenised payments interact more cleanly with exemption logic, and the assurance data network tokens carry supports risk-based decisions that would otherwise force a challenge. Compliance and conversion pull in the same direction here, which is rare enough in payments to be worth exploiting deliberately.
Scope also shapes vendor conversations. A payments provider that supports network tokens on some schemes but not others creates a split estate, where part of the card-on-file book benefits from tokenisation and part does not. Vladyslav Kolodistyi treats scheme coverage as the first question to ask any payments partner.
“Ask which schemes the network tokens actually cover, not which ones the roadmap mentions,” says Vladyslav Kolodistyi. “Partial tokenisation gives you partial results and a reporting problem, because your blended approval numbers now mix tokenised and untokenised payments with no way to separate them.”
Reporting deserves its own attention. Tokenisation changes what a payments dashboard is measuring, and teams that do not instrument the migration cannot prove the benefit. The useful comparison is not before and after across all payments, but tokenised versus untokenised card-on-file payments inside the same cohort over the same period.
Cross-border payments are where network tokens tend to earn their keep fastest. Issuers outside the merchant’s home market have the least context on a raw card number, so the assurance data that network tokens carry does the most work there. Merchants running heavy cross-border card-on-file volume usually see the steepest improvement once network tokens are in place.
There is an argument about who should own the tokenisation programme. Vladyslav Kolodistyi puts it with the payments team rather than with security, on the grounds that the decisions are commercial.
“Security will scope tokenisation correctly and stop there,” he says. “The payments team is the one that cares whether network tokens lift approvals on card-on-file payments next quarter. Ownership determines whether tokenisation becomes a compliance artefact or a revenue programme.”
For merchants starting from scratch, Vladyslav Kolodistyi’s advice is to fix acquisition before migration. “Tokenise every new credential from day one,” he says. “Then migrate the back book. Teams do it in the opposite order, spend six months on migration, and keep adding untokenised card-on-file records the whole time. You cannot drain a bath with the tap running.”
Timing is the last variable worth planning. Network tokens deliver most of their value on aged credentials, so a payments team that waits a year is not standing still: it is accumulating card-on-file records that network tokens will later have to rescue. Vladyslav Kolodistyi frames the delay cost plainly.
“Every quarter without network tokens adds credentials that will fail later,” he says. “Tokenisation is one of the few payments projects where the cost of waiting is measurable in the next billing cycle rather than in some distant risk scenario.”
Migration itself is less dramatic than most payments teams expect. Schemes support bulk conversion of stored credentials into network tokens, and the merchant-facing work is usually reconciliation rather than integration. Most payments platforms request network tokens on capture automatically once the feature is live. What takes time is proving that tokenised payments and untokenised payments were compared honestly.
The wider trajectory is not in doubt. Tokenised payments already run into the hundreds of billions of transactions annually and keep growing, and network tokens are steadily becoming the default representation of a stored card rather than an optimisation applied to one. Payments platforms built after 2024 increasingly assume network tokens by default, which quietly widens the gap between them and older estates where tokenisation was retrofitted.
Further commentary from Vladyslav Kolodistyi on tokenisation and payments architecture is available through his LinkedIn profile.
The card number sitting in a merchant database is doing nothing useful. The argument Vladyslav Kolodistyi makes is that it is not only a liability but a slow leak in recurring payments revenue, and that tokenisation closes both at once.
This article has been published in accordance with Socialnomics‘ disclosure policy.