The CRT Playbook: Cracking Cardless Payments in Commercial Transport (2)
- Nick Pannell
- Dec 11, 2025
- 7 min read
About the series 'The CRT Playbook'
Commercial road transport isn’t corporate fleet, but most innovation in mobility payments still treats it that way. In a sector defined by long routes, high exposure, thin margins, and real operational risk, “more convenience” isn’t a strategy. Control is.
That’s why The CRT Playbook exists. In this series, we cut through the noise to examine the technologies, behaviours, and market dynamics that actually shape the CRT ecosystem. From fraud and fuel leakage to tokenisation, telematics, data reconciliation, and the road to a truly cardless future.
Every chapter builds on the last. Welcome to Chapter 2 of our CRT Playbook.
If you are just joining us, you can find the previous chapters here.
Apps, Codes, Tokenisation, and the 360° Fraud-Proof Solution
In our last blog, we explored an uncomfortable truth: most mobility-payment innovations are built for the wrong segment. Designed through the lens of corporate-fleet convenience, they rarely address the realities of commercial transport — a world defined by high exposure, cross-border operations, fraud incentives, leakage risk, and razor-thin margins.
In CRT, convenience is not the north star.
Control is the operating system.
So if removing plastic cards from drivers’ cabs is essential — and most operators agree that it is — what replaces them?
Apps look like the obvious answer… until you examine the practical, behavioural, and infrastructural constraints that have kept app usage stubbornly low — typically below 5% after more than a decade on the market.
So in this chapter we dig deeper.
Most apps are built for convenience-first use cases — not for the ultra-controlled, multi-boundary CRT environment.
If cardless is the future, what form of cardless actually works for CRT?
What technology fits the segment’s risk profile, operational reality, and international footprint — without disrupting the authorisation and settlement processes fleets already rely on?
That line of inquiry leads us to a very different model: one-time codes, tokenisation, and a 360° control layer that starts at the pump and ends with real-time, fraud-resistant data.
Why Apps Still Aren’t the Answer
Given that fleet operators in commercial transport are keen to eradicate physical fuel cards from their drivers’ cabs, you’d imagine that apps are the obvious way forward. There are plenty of them, certainly. And more on the way — even more certainly.
So why, then, are they not more penetrated? Estimates vary, but the highest we’ve seen is 5%, and that’s likely inflated. For mobile-payments tech that’s been around for a decade, that’s mighty low.
Why?
We’ve looked at several reasons. Here are a few to start with:
Mobile payment apps for commercial transport are often “copy-pastes” from consumer apps, designed for convenience (rather than control).
App-POS integration can be expensive and complex, especially for independently developed apps (i.e., not a fuel retailer’s own).
Cross-acceptance — on which much international refuelling depends — is extremely difficult to engineer for app-based payments.
Many apps still require the existence of a physical fuel card in the background.
The Real Killer: Fleets Don’t Want to Issue Smartphones
…but here’s the real killer, and it couldn’t be simpler.
Particularly in the increasingly dominant international commercial transport segment, there is a very real resistance on the part of fleet managers to issue smartphones to drivers. (There goes your app.)
Put simply: most apps are built for convenience-first use cases — not for the ultra-controlled, multi-boundary CRT environment.
At the edge, drivers need something fast, simple, and robust. A short, one-time code works.
There is another way
But apps failing doesn’t mean cardless fails. In fact, when you look at CRT through a control-first lens, a very different model starts to stand out — one built for low-connectivity environments, rapid driver turnover, and multi-country routes. That’s where one-time codes prove their worth.
As we highlighted in our previous blog, we’ve looked closely at how alternative emerging payments technologies can move closer to the real needs of CRT operators — and this is where the one-time code, we think, gets closer than any rival technology.
Sounds great. But surely it’s not so easy to implement?
How does it actually work?
We’ve looked at this closely. Done our homework. Spoken with innovators. Examined use cases. Checked out case studies. Challenged assumptions. Dug into the payments flows. And a whole lot more (so that you don’t have to).
So, in a mood of startling generosity — rather than leaving it vague, woolly, and high-level — here’s our fully researched guide.
Step-by-step Guide to One-time Code Implementation
Step 1: Replace plastic with a one-time code fleet managers will actually allow drivers to use
At the edge, drivers need something fast, simple, and robust. A short, one-time code works because:
It can be requested ahead of arrival (e.g., within a 3-hour window).
It doesn’t expose a reusable credential.
It can be governed by pre-set rules (products/volumes/sites).
At the pump, the driver selects “Pay by Code”, enters the code received on their (non-smart) phone, and the authorisation engine checks credit and rules before unlocking the pump.
Post-transaction, data flows to both the network back office and the platform. This pattern has been proven at scale in Europe and is comfortably paired with (or phased in alongside) existing card programmes.
Deployments of code-based platforms show tangible benefits: lower administrative overhead, fewer disputed transactions, and fraud reduction through time-boxed, device-agnostic credentials.
Step 2: Tokenise to keep issuer rails unchanged
Issuers and networks shouldn’t need to re-plumb everything. The neat trick is tokenisation: at authorisation time, convert the code into virtual Track-2 card data and let the terminal/host handle the rest “as if” a card were present.
Issuers keep their fraud tooling, cutovers, settlement files, and audit trail. Networks keep reconciliation processes intact. Commercially, this supports per-transaction licensing rather than a big-bang capex wave.
Step 3: Choose your integration pattern—on-site or at the switch
There are two pragmatic ways to wire this into today’s infrastructure:
A) Code→Track-2 at the terminal (site conversion).
The terminal asks a code issuer over API, gets back Track-2 for the driver/vehicle, and proceeds like a normal card authorisation.
Benefits: multi-issuer capable, existing card checks (IIN validation, product controls, mileage capture) still apply at site; settlement/cutovers remain “as is.” Requires terminal support for a Code entry path and an API call.
B) Code→Track-2 at the switch (central conversion).
The site passes the code (wrapped in PAN/Track-2 fields per IFSF) to the switch, which calls the code issuer, receives Track-2, and forwards a standard card message upstream.
Benefits: less change on site, single integration between switch and code issuer. Trade-offs: you’ll need governance to keep IIN and acceptance rules under network control; all issuers’ code transactions may appear as one method of payment operationally.
Either path keeps host, switching, reconciliation, settlement, and help-desk processes essentially unchanged—critical for CRT operators with thousands of sites and multiple issuers.
Step 4: Make the controls real-time, not just reporting
The real payoff isn’t “no plastic”; it’s live control. With digital authorisation you can enforce:
Product & volume caps per vehicle/driver/country
Time windows & site lists (including cross-border geofences). Also reducing “leakage” – more about this in our next blog.
Credit/risk checks before nozzle lift
Per-vehicle traceability into fleet/ERP for audits
Deployments of code-based platforms show tangible benefits here: lower administrative overhead, fewer disputed transactions, and fraud reduction through time-boxed, device-agnostic credentials.
Step 5: Close the litre gap with telematics and/or tolls integration
Payment data tells you what was bought. Telematics/toll data tells you what actually happened to what was bought.
Fuse them, and you approach a 360° fraud-proof model:
Location match
Tank-level plausibility
Route/OBU evidence
Driver identity
Everything tied to one authorisation; that’s the difference between catching anomalies next month and preventing them at the pump.
Getting right to the heart of what matters in Commercial Transport
No new payment technology is going to “land and expand” unless it’s capable of making a substantial difference to the commercial and operational KPIs of the operators who deploy it. That should go without saying.
Cardless payments in commercial transport will — without doubt — be the model of the future.
We’ll say it again – just in case we haven’t got the point across yet: CRT is about control – not convenience. And it should come as no surprise that the leading KPIs are all based around control.
So what are those KPIs?
These are the KPIs CRT operators actually live and die by — and the KPIs most generalised mobility solutions never move:
Fraud delta: € fraud per 1,000 transactions (baseline vs pilot)
Admin time: minutes per transaction to reconcile and approve
Driver dwell: time from “arrive at pump” to “nozzle lift”
Chargeback/dispute rate: pct. of transactions escalated
Adoption & compliance: % of fills on cardless + % within rules
Leakage: % of fuel spend at sites with negotiated discount vs premium pricing
Well okay. But that’s a big jump into the unknown. Is it possible to step in without huge exposure?
We’re not going to pretend it makes sense to jump in at the deep end without water wings. Any new technology needs to be tried, tested, validated against success criteria, and risk-assessed before rollout.
That’s why a controlled pilot makes sense.
And as we’re feeling generous (see above), here’s a pilot skeleton that helps you road-test the model in a controlled environment — low risk, high learning.
A 90-day pilot you can actually run
Weeks 0–2: Design & contracts
Corridor selection (3–5 sites, two countries)
Stakeholder roles (friendly fleet + issuer/network + switch/terminal + telematics/tolls)
Pick site vs switch conversion
Confirm required terminal features or switch wrappers
Weeks 3–6: Build & configure
Code request channels (app, SMS, in-cab tablet/TMS)
Code validity + rule sets (products, volumes, sites)
Tokenisation response (virtual Track-2)
Host acceptance tests, cutover tests, settlement tests
Weeks 7–10: Soft launch
10–20 trucks
Monitor dwell + anomaly alerts
Human-in-the-loop overrides
Weekly KPI reviews; adjust limits
Weeks 11–13: Scale or sunset
If KPIs meet thresholds: expand to 50–100 trucks and 10–15 sites
If not: document blockers and iterate
So here’s the bottom line
Cardless payments in commercial transport will — without doubt — be the model of the future.
One-time codes offer the best fit with fleet, issuer, and network needs.
Tokenisation preserves issuer rails.
Telematics/tolls integration makes it tamper-resistant.
Implementation is comparatively straightforward.
Put these factors together and you may just achieve an integrated, CRT-specific payments stack that increases control, saves time, eliminates unauthorised spend, and reduces fraud — without ripping out the core.
In our next article, we’ll go deeper into leakage — the silent profit drain in CRT — and how cardless controls change the economics of route behaviour.
Ready to rethink CRT?
If there’s one thing the CRT market proves, it’s that doing “more of the same” stops working fast. Costs rise. Fraud adapts. Margins tighten. And the old playbook — plastic cards, patchwork controls, and endless admin — simply can’t keep up.
If you’re ready to explore what better looks like, we’re already deep in the details.
Get in touch with PHC Mobility and let’s map out your next move.
Comments