Network Tokenisation and the Approval-Rate Problem Nobody Owns
Somewhere in most businesses that take card payments online, there is a number that quietly costs more than almost any other, and almost nobody is accountable for it. It is the authorisation rate, the proportion of payment attempts that the issuing bank actually approves. Payment approval rates get watched from a distance; they rarely get owned.
When it slips, the symptoms surface everywhere except where the cause lives. Growth sees conversion dip. Finance sees revenue soften. Support sees complaints about "my card was declined and it works everywhere else." The subscription team sees churn tick up. Each team investigates within its own domain, finds nothing conclusive, and moves on. The rate stays where it is, and the leakage continues, because the thing that actually determines it sits between all of them and belongs to none of them.
That thing is the quality of the card credential being sent at the moment of authorisation. And the most effective lever on it, network tokenisation, is understood by very few of the people whose numbers depend on it.
This article is about that lever and that ownership gap. It is deliberately about mechanics rather than architecture: not how to structure an orchestration layer, but what actually happens to a card credential between "customer clicks pay" and "issuer says yes", and why so much recoverable revenue is lost in that gap.
The mistake: treating approval rate as the acquirer's number
The default assumption in most organisations is that the authorisation rate is something the acquirer controls, and therefore something you manage by choosing or pressuring your acquirer. This is mostly wrong, and the misconception is the reason the problem goes unowned.
The acquirer routes the transaction and can influence a few things at the margin. But the actual approve-or-decline decision is made by the issuing bank, in a fraction of a second, based on the information that reaches it. The issuer is asking, in effect: do I trust that this is a legitimate cardholder making a legitimate purchase on a valid card? The quality and richness of the data that answers that question is what moves the rate, and most of that data is determined by decisions made long before the acquirer is involved.
Two failures dominate. The first is stale credentials: the card on file has expired, been reissued, or been replaced after a fraud event, so the number being sent is simply no longer valid. The second is thin authentication data on the credential-on-file: the issuer receives a bare card number with little to distinguish a legitimate returning customer from a fraudster who bought a card dump, so it declines out of caution. This second category, the false decline, where a good customer is wrongly rejected, is pure lost revenue with an angry customer attached.
Neither of these is the acquirer's fault, and neither is fixed by switching acquirers. Both are credential-quality problems. Which is exactly why network tokenisation matters.
What network tokenisation actually is
A network token is a scheme-issued replacement for the card number, provisioned to a registered token requestor and mapped to the real card inside the network's token vault. Instead of storing and sending the raw 16-digit primary account number (the PAN), the merchant stores a token issued by the card network itself, Visa Token Service, Mastercard's MDES, American Express Token Service, that stands in for that specific card, at that specific merchant. This is the mechanism behind proper card-on-file tokenisation: the stored credential is a scheme token, not a raw number.
It is worth separating this clearly from the other thing the industry calls "tokenisation", because conflating them causes real confusion. A PSP token, or gateway token, is a reference number your payment provider generates to represent a stored card inside its own vault. It reduces your PCI scope and lets you charge a saved card without holding the raw number, which is genuinely useful. But it is meaningful only inside that one provider, and this is the crucial part, it does not update when the underlying card changes. It is a private nickname for a PAN, and when the PAN dies, the nickname dies with it.
A network token is different in two ways that matter enormously for approval rates.
First, it carries assurance. When a network token arrives in an authorisation request, the scheme validates it before passing the request to the issuer, confirming the token was legitimately issued, that domain restrictions are satisfied, and that the per-transaction cryptogram is valid. The issuer therefore receives an issuer authorisation request the network has already vouched for, which is a materially stronger trust signal than a raw PAN. That is why issuers approve tokenised transactions more often.
Second, it is bound to the account, not the physical card. When the customer's card is lost, stolen, expired or upgraded and the issuer reissues it, the network token updates in the background. The old plastic dies; the token keeps working. The next charge goes through without anyone contacting the customer.
Those two properties, richer trust data and a self-updating credential, are precisely the two things that fix the two dominant causes of declines.
The numbers the schemes themselves publish
This is not a vendor claim; the card networks publish the effect from their own transaction data.
Visa reports that its tokenised card-not-present transactions have seen a 4.6 per cent lift in authorisats globally compared with PAN transactions, measured on VisaNet, and separately reports around a 30 per cent reduction in online fraud for token versus PAN. Visa also notes that payment issues can drive up to 44 per cent of digital checkout abandonment, a reminder that a decline is not just a lost transaction but often a lost customer. Mastercard reports an average authorisation uplift in a similar range, on the order of a couple of percentage points, from network tokens versus PANs.
The exact figure will vary by region, vertical, issuer and card mix, and any responsible reading treats these as scheme-published directional evidence rather than a guaranteed result for a given business. But the direction is consistent and the mechanism is understood, which is what makes it actionable.
The scale is easy to underestimate because the percentages sound small. Consider a business processing $50 million a year in card volume at a 91 per cent authorisation rate. Closing even a few points of that gap through better credentials recovers seven figures annually, revenue that is currently leaking not through any commercial failure, but through stale card data and thin authentication. That is the shape of the prize, and it is why the ownership gap is so expensive.
Account updater: the other half of the credential story
Network tokens are one of two complementary mechanisms, and the second, the account updater, is frequently confused with them.
An account updater works on raw PANs rather than replacing them. Visa's is the Visa Account Updater; Mastercard's is the Automatic Billing Updater. The merchant or processor sends a stored card reference, the network queries the issuing bank, and an updated card number or expiry is returned if the card has been reissued. It refreshes the credential rather than tokenising it.
There are two delivery models, and the distinction has cost consequences. Batch updating runs periodically, overnight or weekly, refreshing the stored vault before the next billing cycle. Real-time updating queries the network immediately before a transaction attempt, which matters most for high-value recurring accounts where a single failed renewal triggers a recovery workflow that costs more in overhead than the query itself.
The relationship between the two is worth stating plainly, because it drives the right investment sequence. Network tokens auto-update by design, so as network-token coverage grows, reliance on the account updater diminishes for those credentials. But coverage is never complete, not every card, scheme or region is tokenised, so the account updater remains the safety net for the PAN-based remainder. A serious credential strategy uses both: network tokens as the primary mechanism, account updater covering what tokens do not yet reach.
Where this hits hardest: recurring billing and involuntary churn
For any subscription or recurring-billing business, the credential problem has a specific and measurable name in involuntary churn, the involuntary churn payments teams see when a renewal fails on a dead card. This is the customer who did not decide to leave, whose subscription simply lapsed because a renewal payment failed on a card that had expired or been reissued.
It is insidious precisely because it is invisible as a decision. The customer still wants the service. They have not complained, not compared you to a competitor, not been tempted away. They just have a new card in their wallet, and the number you have on file is now dead, and that quiet failure is a large share of subscription churn. The first they hear of it may be a "your subscription has ended" email that reads, to them, like your failure rather than their bank's reissuance.
A widely cited Mastercard analysis of recurring billing has put payment-credential failures at roughly 40 per cent of involuntary subscription churn. The significance of that figure is what it implies about where the fix lives. Retry logic, dunning sequences, smart repayment scheduling and win-back emails all address the symptom, a payment that has already failed. Network tokenisation and account updater address the cause: they keep the credential valid so the payment does not fail in the first place. The dunning stack is still worth having, but it is catching what the credential layer should have prevented.
For a subscription business, this reframes network tokenisation from a payments-team optimisation into a retention initiative, which is exactly why it should matter to whoever owns churn, and exactly why it usually falls through the cracks between them and the payments team.
Why nobody owns it
Here is the structural reason the approval-rate problem persists even in sophisticated organisations. The lever that moves it does not sit inside any one team's mandate.
The payments or finance team understands acquirers and cost, but often treats authorisation rate as a given rather than an engineering-influenced variable, and rarely owns the card-on-file storage where credentials live.
The engineering team owns the credential storage and the integration to the gateway, but is measured on uptime and delivery, not on authorisation rate, and has no commercial reason to prioritise a token migration over the roadmap.
The growth or ecommerce team owns conversion and feels the decline problem acutely, but sees it as a checkout-funnel issue and has no visibility into credential mechanics.
The subscription or billing team owns churn and suffers the involuntary-churn cost directly, but usually attacks it through dunning and retries, the symptom layer, because that is what sits within reach.
The fraud team owns decline-related risk, but is incentivised to be conservative, which can push false declines up rather than down.
Every one of these teams touches the problem. None of them is measured on the single metric, authorisation rate, that would make the credential layer their responsibility. So the token migration that would lift the rate is everybody's good idea and nobody's current objective. The first and most important intervention is therefore not technical at all: it is naming an owner and a number.
The credential-quality checklist worth running
Before any platform decision, a business can diagnose most of its exposure with a handful of questions that cut across the teams above.
What proportion of our stored, card-on-file credentials are network-tokenised today, by scheme? For many businesses the honest answer is "we don't know", which is itself the finding.
Are we passing network tokens all the way through to authorisation, or tokenising for storage and then sending the PAN anyway? The benefit only lands if the token reaches the issuer.
Do we have an account updater running, and is it batch or real-time, and does its coverage match where our revenue actually concentrates?
For card-not-present flows, are we passing rich authentication data, 3D Secure 2 and its associated context, so the issuer has a reason to approve, or a bare credential it has reason to doubt?
What is our authorisation rate, and can we even see it split by tokenised versus non-tokenised, by card type, and by first attempt versus retry? If the reporting cannot answer that, the metric cannot be managed, and the ownership gap is guaranteed.
And who, by name, is accountable for that authorisation-rate number next quarter? If the answer is a shrug, that is the root cause, and no amount of tokenisation fixes an unowned metric.
Getting the credential layer right
The outcome worth aiming for is straightforward to state and valuable to reach: a higher authorisation rate, fewer false declines, lower involuntary churn, and a card-on-file estate that quietly stays valid as customers' cards turn over, with the PCI scope reduction that comes from not handling raw card numbers as a genuine bonus rather than the headline.
Getting there is part technical and part organisational. The technical work is real, provisioning network tokens through the schemes or a provider that connects directly to Visa Token Service and MDES, ensuring tokens flow through to authorisation rather than stopping at storage, layering an account updater over the untokenised remainder, and passing full authentication data on card-not-present transactions. But the organisational work comes first, because a credential migration with no owner and no visible authorisation-rate metric will lose to the roadmap every quarter, however sound the technical case.
This is where specialist help earns its place. Conexxia works with Australian ecommerce and subscription businesses on the credential layer that determines authorisation success, assessing network tokenisation coverage, connecting card-on-file flows to scheme token services, and closing the ownership gap so approval rate becomes a metric someone actually manages. It is the same evidence-led approach we bring across our payments consulting practice, and it complements the architecture-level work we do on payments orchestration strategy, payments operations, cross-border payments, and payments compliance and risk.
None of this requires re-platforming to begin. Most businesses start by measuring one thing they have never measured, the share of their stored credentials that are network-tokenised, and the authorisation rate split by tokenised versus not, and letting that single comparison make the case.
If your approval rate is everyone's concern and no one's responsibility, that is the gap worth closing first.
Aftab Khan
Head of Payments Consulting
On a mission to help change the world, one experience at a time
I collaborate with progressive businesses to deliver successful business outcomes in 4 key areas: Increasing Revenues, Improving Operational Efficiencies, Regulatory Compliance and Elevating Customer Experience, leading to sustainable business growth.
Comments