The Ad-Hoc Challenge: Terminals, Apps, & Roaming Under AFIR

The first quarter after the AFIR (Alternative Fuels Infrastructure Regulation) ad-hoc payment mandate took effect has been a quiet one for press releases and a busy one for operations teams. New contactless terminals are bolted onto every chassis. Mobile apps have been refreshed. OCPI (Open Charge Point Interface) integrations have been fast-tracked to roaming hubs. The compliance boxes are checked.

What is not yet checked is whether the three payment paths a public charger now accepts — the in-charger terminal, the operator’s mobile app, and roaming partners reaching the station via OCPI — actually agree on what just happened. AFIR Article 5 specified the channels. It did not specify the architecture behind them. And the gap between accepting an ad-hoc payment and reconciling one is where most charge point operators are quietly burning operations cycles in 2026.

For the audiences building, scaling, or buying an EV charging payment system right now, this is the next conversation. Not “are we compliant?” but “is our payment stack one system or three?”

Compliance Got You to “Accept.” Operations Has to Get You to “Reconcile.”

AFIR Article 5 requires public charging operators to offer ad-hoc payment via a contactless card reader (on chargers ≥50 kW), an internet-connected QR/app interface, or a secure roaming arrangement. The intent is straightforward: a driver in any EU member state can pull up to a public charger and pay, no contract, no app download, no loyalty card, no friction. By April 14, 2026, operators must also publish their pricing and availability data in DATEX II format to National Access Points so that drivers can compare prices before they arrive.

What the regulation says nothing about is how an operator should ensure that the price the driver sees on the terminal display, the price shown in the app, and the tariff transmitted to a roaming partner all match — and continue to match every minute, every session, every CDR. That is an architecture decision. Most operators, having raced to install hardware before the January 8, 2026 deadline, have not made it yet.

The early signals from the field are unambiguous. J.D. Power’s 2025 EVX Public Charging Study found 14% of EV drivers visited a public charger and failed to charge — the best year-over-year improvement in four years, and still nowhere near acceptable. NREL’s analysis of US payment system reliability identified payment-side failures as among the most cited driver pain points. The point is not that the EU is trailing the US — it is that AFIR has just made every European public charger subject to the same operational stress test, and the failure modes are well understood.

Three Channels, One Driver: The Anatomy of an Ad-Hoc Session

The architecture problem becomes obvious once you trace one charging session through the three payment methods AFIR contemplates.

A driver pulls up to a 150 kW charger on a TEN-T corridor. They could tap a credit card on the contactless terminal. They could open the operator’s mobile app and scan a QR code. They could be roaming from a different operator and authenticate via OCPI. Three doors into the same charger.

Behind those doors, in many networks today, are three different systems. The terminal vendor’s stack handles the card transaction and reports it to one backend. The mobile application speaks to the operator’s CSMS over a separate API and runs its pricing logic in the app. The OCPI Tariffs and CDR modules push pricing and session data to the roaming hub on yet another schedule. Each was built for a single channel. None was built to publish a consistent answer when the same driver could have used any of them.

The same charging session, traced through the three AFIR-compliant ad-hoc payment channels. Each channel is typically wired to its own backend, with its own pricing logic and its own session record — which is why divergence is the default outcome, not the exception.

Layer	Contactless terminal	Operator mobile app	OCPI roaming
Driver experience	Tap-and-go: credit/debit card, mobile wallet, no app required.	App-led: driver opens the operator’s app, scans QR or selects the charger.	Home-network: driver authenticates via their eMSP’s app, charges on a partner CPO.
Where pricing usually lives	Terminal vendor stack: tariff cached locally, refreshed on a vendor schedule.	App backend: tariff served from a CPO API, often with its own caching layer.	OCPI Tariffs module: pricing pushed to the eMSP via OCPI 2.2.1; CDR generated post-session.
Session record source	Terminal transaction log, sometimes reconciled against the CSMS hours later.	App session model, read from the CSMS but cached for the user.	OCPI CDR, generated by the CPO from session data after the connector is released.
Failure mode when systems drift	Terminal shows a stale price; driver disputes the bill.	App quotes a different price than the terminal; user complains.	Roaming partner invoices a third price; bilateral dispute opens.
AFIR consequence	Price-transparency rule violated at the charger.	Price-transparency rule violated in the operator’s own UX.	Price-transparency rule violated for cross-border drivers.

The driver does not see this. They see a price on the terminal, a different price in the app they happened to open, and — if they are a roaming customer — a third price on the invoice their home operator forwards a week later. Nobody is wrong. Nobody agrees. And the AFIR price-transparency principle, which expects the price displayed before the session to match the price billed after it, breaks at the first divergence.

For the operations team, this is what is consuming Q2 mornings. CDRs that do not match terminal logs. App users charged at a tariff that was active when the session began but updated mid-session. Roaming partners filing dispute tickets every week. None of these are compliance failures in isolation — they are reconciliation failures that compound until the audit trail itself becomes the liability.

Why the Pricing Layer Has to Be Canonical

AFIR’s price-transparency rule has a deceptively simple test built into it. For chargers at or above 50 kW, the price per kWh shown to the driver before the session must be the price billed after the session. There is no provision for “the app price” versus “the terminal price” versus “the roaming price.” There is one price, attached to one session, applied to one driver.

That requirement is impossible to satisfy with three independent pricing engines. The moment a tariff change is published — a time-of-use shift, a grid-signal-driven dynamic price, a promotional rate — three engines must update simultaneously. They will not. One will lag. One will hold a stale value. One will get the update but apply it to a session that has already started. The reconciliation team will reverse the discrepancies, and a week later it will happen again.

The fix is not faster updates across three systems. The fix is one system: a canonical pricing service that holds the single authoritative tariff for every charger, every connector, every time window. The terminal display reads from it. The mobile app reads from it. The OCPI Tariffs module — the layer that publishes pricing to roaming partners — reads from it. When the price changes, all three channels see the change in the same event, in the same second, applied to the same session boundary.

This is exactly what the OCPI 2.2.1 protocol was designed to enable on the roaming side: real-time tariff distribution from the CPO backend to every eMSP partner, expressed as per-kWh, per-minute, or session-based formats. But OCPI is only the publication layer. The protocol cannot create consistency that does not exist upstream. If the CSMS holds a different tariff than the terminal, OCPI will faithfully transmit whichever one it was wired to read. The canonical layer is the architectural decision that makes the protocol useful.

What “One Layer, Three Channels” Looks Like in Architecture

Designing the orchestrated EV charging payment solutions that AFIR effectively forces involves three interlocking responsibilities, all owned by the CSMS rather than the terminal, the app, or the roaming module.

The session is the unit of truth. OCPP 2.0.1 already defines the session record — TransactionEvent, MeterValues, StatusNotification. These messages capture every authoritative fact about what happened at the charger: who plugged in, when, how many kWh flowed, how the connector was released. Every downstream artifact — the terminal receipt, the in-app session summary, the OCPI CDR — should derive from this single record. When three independent systems each generate their own session record, divergence is guaranteed. When all three render the same upstream record into channel-specific formats, divergence becomes a defect rather than a design feature.

Pricing is a service, not a column in a database. A tariff is not a static value attached to a charger; it is a function evaluated against a session in motion. A canonical pricing service exposes one API. The terminal, the driver app, and the OCPI Tariffs module each call it. Time-of-use logic, grid-signal-driven dynamic pricing, occupancy fees, promotional rates — all of it lives in one place. Updates propagate to every channel through the same event stream. AFIR’s “what is shown is what is billed” requirement becomes an architectural property rather than a daily reconciliation chore.

Settlement reads from the canonical record, not from each channel. Whether the operator is invoicing a direct customer, settling a roaming charge with a hub, or filing a NAP report, the data should originate from the same OCPP-anchored session, priced by the same canonical service. The accounting layer, the billing software for EV charging, and the roaming reconciliation pipeline all read the same view of the same truth.

Two ways to deliver an AFIR-compliant ad-hoc payment system. The bolted-on path satisfies the regulation on day one and quietly accumulates operational debt. The orchestrated path requires more up-front design but pays off across reconciliation, NAP reporting, and the 2027 NC DR flexibility market.

Architectural property	Bolted-on (three-stack) approach	Orchestrated (canonical-layer) approach
Session record	Three independent records (terminal log, app session, OCPI CDR) that must be reconciled after the fact.	One OCPP-anchored session rendered into channel-specific outputs; no reconciliation required because there is one source.
Pricing logic	Three pricing engines with their own update cycles; tariff changes drift across channels.	One canonical pricing service queried by all channels; changes propagate atomically.
AFIR price transparency	Achieved on a good day, broken whenever a tariff updates mid-session or between channels.	Architectural property — the same input produces the same answer everywhere, by design.
NAP / DATEX II reporting	Stitched together quarterly from three vendor exports; high audit risk.	Generated from the canonical session record; auditable end-to-end.
Roaming dispute load	Recurring; reconciliation team handles dozens of partner tickets per month.	Marginal; disputes become defects rather than business as usual.
2027 NC DR readiness	Real-time grid visibility blocked — flexibility data must be reconstructed from siloed sources.	Real-time grid visibility available natively — same data layer that supports billing supports flexibility dispatch.
Build effort	Lower up front; high recurring operations cost.	Higher up front (CSMS architecture decision); near-zero recurring ops cost once stable.

This is the orchestration pattern Codibly’s CSMS/CPMS development, OCPI Accelerator, eMSP Engine, and OCPP Accelerators are designed around. The accelerators provide the certified, production-tested protocol implementations. The orchestration logic — pricing service, canonical session, unified settlement — is what binds them into one operational stack rather than three. Operators who already had a unified EV charging billing software layer in late 2025 are the ones running quiet operations teams in 2026. Operators who bolted on a contactless terminal in December are the ones running daily firefights.

The Summer Stress Test: Why “Social Chargers” Will Expose This

This is not a Q3 problem to defer. It is a Q2 problem that becomes a Q3 catastrophe if the architecture choice is not made now.

European EV travel concentrates ferociously in July and August. Tourist corridors fill with drivers who have never used the local CPO’s network and never will again. They have no app, no RFID card, no loyalty account. They have a credit card and a willingness to charge if it works on the first try. These are “social chargers” in the literal sense — the charger has to work for a stranger.

For the social driver, all three of AFIR’s ad-hoc channels are equivalent points of failure. The contactless terminal is the obvious one — if it cannot read the card, the session never starts. The mobile-app QR path matters when the terminal is busy or unavailable. The roaming path matters because most drivers on a foreign holiday network are, by definition, roaming. A reliable EV charging station payment experience requires that all three work, with consistent pricing, on the first attempt.

Networks that orchestrated their pricing engine in spring 2026 will pass this test. Their summer-peak operations will see the volume but not the dispute backlog. Networks that did not will discover, in real time, that a bolted-on architecture cannot be fixed during the peak — only patched. The retrofit deadline of January 1, 2027 will then arrive with the operations team already exhausted.

There is a second, longer reason to make the architecture decision now. The same canonical session, canonical pricing, and unified settlement layer that solves the AFIR ad-hoc problem is exactly what the Network Code on Demand Response will require when EU flexibility markets open in 2027. Grid operators dispatching demand response signals expect real-time visibility into every active session, every available kW, every connected vehicle’s state. Networks that built three siloed payment paths in 2026 will not be able to expose that visibility in 2027 without rebuilding the data layer they already paid to install.

From Three Backends to One Operating Model

The AFIR ad-hoc payment requirement looked, on paper, like a hardware story. Install the terminal, ship the app, integrate the roaming hub, file the compliance attestation. The hardware was the visible work, and the regulatory deadline was the visible pressure.

The operational reality of running those three channels in production is a software story. The operators who treated AFIR as an architecture project — building the canonical session, the canonical pricing service, and the unified settlement layer that all three channels read from — entered Q2 with one operating model. The operators who treated it as three deployment projects entered Q2 with three. The pricing transparency that AFIR promises drivers, and the audit trail that NAPs and regulators demand, both depend on which path was chosen.

The decision is not technically hard. It is organizationally easy to defer. The operators who do not defer will spend the rest of 2026 building a payment stack that will still be the right architecture in 2027 when the flexibility revenue starts. The ones who defer will spend it managing tickets.

So the question worth asking, before the summer peak forces an answer, is the architectural one. When a driver taps a card on your terminal, opens your app, or arrives via a roaming partner, are all three channels asking the same system the same question — and getting the same answer?