The cardless driver still has a card
There is a kind of driver who never carries plastic. Pays for coffee with a watch, taps a phone at the supermarket, hasn’t pulled a physical card from a wallet in months. Ask whether that person can charge at an unattended DC charger with a contactless reader, and the instinct is to reach for an app: surely the cardless need a download, a login, a stored profile.
They don’t. The card is already in the phone.
A contactless tap at the charger accepts Apple Pay and Google Pay the same way it accepts a bank card, because that is what an EMV contactless reader does. It speaks to whatever NFC instrument is presented, and a provisioned wallet is a card to the reader. No special integration. No SDK on the driver’s device. The driver who hasn’t touched a physical card in months presents the phone they already carry, and the pre-authorization fires exactly as it would for plastic.
This is a small fact with a large consequence. The universality argument for a card terminal at the charger usually rests on “every driver has a card.” The wallet quietly extends that to the drivers who don’t — and it does so without anyone building anything.
Why the tap covers the wallet for free
AFIR’s requirement for new high-power points is specific: card-present acceptance via a contactless reader, at the point of charge, with no app and no account. The mobile-wallet behaviour comes along as a property of the hardware that satisfies the rule — not a second feature you bolt on.
A modern EMV contactless terminal doesn’t know, and doesn’t care, whether the NFC field it’s reading comes from a card body, a phone, or a watch. It runs the same contactless transaction profile either way. So the moment a charger has a reader that satisfies AFIR for physical cards, it satisfies Apple Pay and Google Pay too. The acceptance surface widened, and no one wrote a line of code.
That is the cleanest version of the universality claim, because every other access method carries a tax:
- An app means a download and a registration before the first electron flows.
- A QR code routes through a screen that can be overlaid or swapped, and almost always dumps the driver into a web form or an app install anyway.
- Plug & Charge is genuinely elegant when the car authenticates the cable — but it needs vehicle and contract provisioning, ties to an eMSP relationship, and is only partially rolled out.
Every one of those routes asks the driver to become a user of something. The tap asks for nothing. The driver already onboarded — to their bank, and to their phone vendor — long before they walked up to a charger they had never seen. You inherit an onboarding you didn’t run.
The wallet is your security architecture, not just your convenience
The interesting part isn’t that wallets are convenient. It is what a wallet does to the card data.
When a card is provisioned into Apple Pay or Google Pay, the real card number — the PAN — is replaced by a device-specific token. The number that travels across the NFC field at the charger is not the PAN; it is a surrogate, useless outside the device, paired with a cryptogram the device generates per transaction. The driver’s actual card number never reaches the terminal, never reaches the charger, never lands anywhere in the operator’s stack. (The issuer and payment network still map the surrogate back during authorization — but that happens far from the parking bay, in systems the operator never touches.)
For an unattended terminal standing in a parking bay in the rain, that is exactly the right property. The most sensitive thing a payment touches simply isn’t present in the riskiest part of the system.
Tokenization at the wallet layer is scope minimization the driver already brought with them.
That is precisely what good design tries to do everywhere: shrink the blast radius by keeping sensitive data out of scope wherever it isn’t strictly needed. PCI DSS discipline is the same instinct — engineer so that the fewest possible components ever see cardholder data. A tokenized wallet transaction takes a slice of that work off your hands before the tap even lands.
So the wallet isn’t a nicety layered on top of a secure design. For the drivers who use it, it is part of the secure design.
None of this is your app
Here is the line that matters for an operator deciding what to build: the wallet that authenticates the driver is not yours — and that is the point.
Apple Pay and Google Pay are the driver’s relationship with their phone vendor and their bank. The biometric prompt, the device token, the issuer’s risk checks, the fraud monitoring on the wallet — all of it is infrastructure that already exists, is maintained by parties with enormous incentive to keep it working, and costs you nothing to inherit. You are not running a wallet. You are not storing a credential. You are accepting a tap.
Contrast the alternative. The moment you decide your app is the access method, you own the identity problem forever: the account system, the stored payment methods, the password resets, the abandoned registrations at the charger in the cold, the compliance surface of holding payment instruments, the support load of a login that won’t. And you own it for a population that mostly already pays for everything else by tapping a phone — so you’d be rebuilding, worse, something they already have.
The terminal-payments approach declines that ownership on purpose. The driver presents whatever instrument they carry — a card, a watch, a phone with a tokenized card inside it — and the money flow behind the tap is what has to be right: the pre-authorization tied to the tariff, the hold captured down to the real settled amount, the unused portion refunded cleanly, the fiscal receipt the tax office actually accepts arriving by link at the end. That is the hard, durable problem. The access method shouldn’t be a problem at all — and with a contactless reader it isn’t, for plastic and wallets alike.
What the operator actually inherits
The standard pitch for ad-hoc terminal payments is “no app required.” The wallet sharpens it into something stronger: no app required, even for the drivers who never carry a card. But the deeper point isn’t what the driver skips. It is the asymmetry between what the driver spent and what the operator received.
The driver spent nothing. No download, no account, no learning this operator’s brand. They used the same gesture they use to buy groceries, and they brought their own onboarding with them.
The operator, meanwhile, received an entire security and identity apparatus it never had to build or maintain:
- A bank’s fraud monitoring on every wallet transaction.
- A phone vendor’s biometric gate in front of the card.
- A payment network’s tokenization standing between the cardholder’s account number and the unattended box in the parking bay.
None of it on the operator’s books, none of it the operator’s liability — all of it switched on the instant the AFIR-mandated reader went in. That is a rare trade: the more your access method does nothing of its own, the more it inherits from systems built by parties far better resourced to run them.
What’s left for the operator to own is the part that genuinely belongs to it. Bolt sits behind the terminal and does the unglamorous half: turning a tap into a pre-authorization on the tariff, a capture on the real settled amount, a clean refund of the rest, and a fiscal receipt the local tax office accepts. The charging session and its CDR run over OCPI, while pre-authorization, capture, refund, and fiscalization live in the payments layer — so it works the same against whatever charger, CSMS, or acquirer the operator already runs, with the operator staying the merchant and funds settling to their own bank.
The card was in the phone the whole time. The job was never to issue a card or build a wallet; that work was done years ago by people who do it for a living. The job is to be ready when one taps — and to get everything after the tap exactly right.