There’s a tempting shortcut floating around the EV charging world: take a charger, bolt a card terminal onto it, wire the two together, and call it ad-hoc payments. AFIR makes ad-hoc payment without an app or account mandatory at public chargers — and for new high-power DC sites, it points specifically at a card reader at the point of charging. The pressure is real and the clock is running. The shortcut looks like the fast path.
It is the wrong answer — and the reasoning matters more than the conclusion.
A charger is not a cash register
A charger was designed to do two things: move energy and talk to a backend. It speaks OCPP to a CSMS, reports its state, takes start/stop commands, streams meter values. Nowhere in that design is “settle a card-present transaction, hold an authorization, finalize against an acquirer, emit a fiscal receipt.”
Bolt a POS onto the charger and hard-wire it to the charging logic, and you’ve asked a device built for energy delivery to also be a point-of-sale device. Those are different problem domains — different failure modes, different compliance surfaces, different update cadences. The acquirer’s API moves on one schedule. The fiscal rules move on another. The charger firmware moves on a third. Fuse them into one box and every one of those independent clocks now has to tick in sync, on hardware that was never scoped for two of the three jobs.
That’s not an integration. It’s a load-bearing hack.
The bespoke-integration tax
Walk through what the charger-plus-POS approach actually requires. The terminal has to talk to the charger. The charger talks to the CSMS over OCPP. So the money flow — pre-authorization, start, stop, capture — has to be threaded through a protocol that was never meant to carry it.
OCPP has no native, standardized semantics for “place a hold of this amount, start the session, then capture the delivered energy and release the rest.” It has no object for a payment terminal and none for a settled transaction. So you invent them: custom messages, vendor extensions, a private contract between one charger’s firmware, one terminal’s SDK, and one CSMS build.
The moment you do that, three things become true:
- You’ve broken the open protocol. Your OCPP link is now non-standard. The next CSMS upgrade, the next roaming partner, the next regulator-facing report has to account for your private extension.
- You’ve spent real engineering time on plumbing that produces no differentiation. Nobody charges more because their pre-authorization rides a proprietary OCPP extension.
- You’ve solved the problem for exactly one charger model, from one vendor.
That last point is the killer.
Operators run mixed fleets
No serious operator runs one charger model. They run AC and DC, from multiple makers, bought across years of procurement cycles. AC chargers are still the majority of what’s in the ground. A DC fast charger can cost a large multiple of an AC unit — different capital, different siting, different economics — but the driver standing in front of either one wants the same thing: tap a card, get energy, get a receipt.
Weld your payment solution to one charger model and here’s your roadmap. Vendor A: build the integration. Vendor B: build it again, differently, because their OCPP extensions and firmware hooks aren’t the same. Vendor C: again. A new AC line from an existing vendor: probably again. Every charger model becomes a fresh bespoke project, a fresh certification surface, a fresh thing that breaks on the next firmware push.
The one-off approach doesn’t scale linearly. It fragments and multiplies. You don’t get a payments system — you get a portfolio of brittle, vendor-specific payment systems, each with its own maintenance burden, all of which have to stay correct forever as acquirers, OCPP versions, and fiscal rules keep moving underneath them.
That’s the bill nobody quotes you up front.
App, QR, Plug & Charge: none of them are universal
Before the right answer, clear the field of the other tempting shortcuts.
App-only charging adds a download and a registration before the first electron flows. For a first-time or visiting driver, that’s where conversion goes to die — and on its own it isn’t AFIR-compliant, since the regulation is explicit that ad-hoc access can’t be gated behind an account.
QR codes feel ad-hoc but usually aren’t. Static codes can be stickered over or spoofed; dynamic ones are better but still typically dump the driver into an app or a web payment form — card-not-present economics, more friction, more drop-off.
Plug & Charge is genuinely elegant: the cable authenticates the car, no tapping at all. But it needs vehicle and contract provisioning, has limited rollout, and ties the driver to an eMSP contract. It will never cover every car or every driver. It’s a great lane — not the whole road.
A card terminal is the one mechanism that’s universal. Every driver already has a card. Because it’s card-present, the operator keeps card-present economics instead of the card-not-present markups that quietly eat small sessions. It needs no app, and it’s squarely AFIR-aligned.
The terminal is right. Welding it to one charger is wrong. Those are separate claims, and keeping them separate is the whole point.
The right answer: orchestrate payments over OCPI
Here’s the move. Don’t put the payment logic in the charger. Put it in a payments layer that orchestrates over OCPI — the open interoperability protocol the industry already uses for roaming and regulatory reporting.
This is where the OCPP-versus-OCPI contrast stops being abstract. Where OCPP has no object for a payment terminal or a settled transaction, the DirectPayment module for OCPI 2.2.1 defines exactly that: a Terminal object and a Financial Advice Confirmation. Payment semantics live where the standards body already put them — not bolted into a protocol built to move electrons.
So each piece keeps its one job. The charger handles energy and OCPP to the CSMS. The CSMS does what it does. The terminal does card-present payments. The payments layer sits across the OCPI boundary and orchestrates the money: a pre-authorization tied to a tariff, start and stop, and the Financial Advice Confirmation at the end — OCPI’s object for the final settled amount — over a protocol every modern CSMS already speaks, that regulators already consume, that roaming already runs on.
The difference is architectural, and it’s decisive:
- Universal. The same ad-hoc payment flow works across any charger, any CSMS, any terminal. You don’t re-integrate per charger model — you integrate once, at the OCPI layer, and your whole mixed fleet inherits it.
- No lock-in. The operator stays the merchant of record. Funds settle to their own acquirer; the money never routes through the payments layer. They keep their CSMS over OCPI and can swap terminal vendors, acquirers, and countries whenever they want. Plug and play, every piece replaceable.
- Built to stay correct. When an acquirer API shifts, an OCPI version bumps, or a CSMS release lands, you adapt one layer — not a dozen vendor-specific welds.
It’s also the only place the genuinely hard parts can live. The DirectPayment module standardizes the connection, not the money — it says nothing about pre-authorization strategy, partial captures, refunding the unused hold, sessions that drop mid-charge, or reconciling when the charger and the acquirer disagree. And it defines nothing for fiscalization. A legal receipt is a round trip: the fiscal signature has to travel from the invoicing provider down to an unattended terminal and back, jurisdiction by jurisdiction. OCPI can’t carry that two-way exchange; a payments layer can bridge the terminal and the invoicing provider directly, both ways — a receipt the tax authority accepts, not just a PDF. None of that fits inside a charger, and none of it should.
This is the standards-track direction
This isn’t a contrarian bet against the ecosystem. It’s a bet on it.
The community has already standardized ad-hoc terminal payments through the DirectPayment module — the open, shared way to do exactly this, and it’s heading toward the de-facto international approach. Optechain participates in OCPI governance through the EV Roaming Foundation, helping shape where the protocol goes. The direction of travel is open interoperability, not proprietary charger-to-POS welds.
So the real choice isn’t fast hack versus slow purist architecture. It’s a hack that solves one charger and breaks the open protocol, versus a layer that solves every charger and rides the protocol the industry already agreed on.
Don’t bolt a POS onto a charger. Orchestrate the money over the protocol the charger already speaks — and let every charger you’ll ever own inherit the same tap-and-charge for free.