Charging App vs Roaming Hub

The conclusion first: a charging app vs roaming hub is not a choice between alternatives. They are not in competition. They exist at different layers of the EV charging ecosystem and serve fundamentally different functions. A charging app faces the driver. A roaming hub faces the market. Confusing the two leads to poor infrastructure decisions, and for CPOs and Demand Partners in particular, those decisions have direct commercial consequences.

Where the Confusion Comes From

The confusion between a charging app vs roaming hub is understandable. Both appear to be about accessing charging stations. Both involve software. Both exist, in some form, in the background of every public charging session. But they address completely different problems, and the decision to use one does not replace the decision to use the other.

The charging app is a consumer product. The roaming hub is a market infrastructure. The former is designed so that a driver can find, start, and pay for a charging session. The latter is designed so that a CPO and a Demand Partner can exchange session data, authorise transactions, and settle revenue across networks they do not jointly own. One is visible to the end user. The other is almost entirely invisible — and that invisibility is precisely the point.

A Brief History of How Both Came to Exist

In the earliest years of public EV charging — roughly 2010 to 2015 — neither concept existed in its current form. Operators built proprietary networks. Drivers who wanted to use a CPO's chargers downloaded that CPO's app, created an account with that CPO, and paid through that CPO's payment terminal. Access was siloed by network. If you charged with ChargePoint in one city and arrived in another served by a different operator, you needed a different app, a different account, and often a different RFID card.

This was the original charging app model in its purest, most limited form: a single operator's interface to its own infrastructure. It worked well enough at small scale, in markets where one dominant network controlled most of the chargers a driver was likely to encounter. It did not work at all as networks proliferated and drivers began to expect — reasonably — that they should not need six applications to charge their vehicles across a single country.

The roaming hub emerged to solve the market-side problem that proliferation created. If dozens of CPOs and dozens of eMSPs needed to exchange session data and settle payments, the bilateral approach — every CPO negotiating a direct agreement with every eMSP — would produce a combinatorial explosion of integrations that no organisation could manage sustainably. A CPO with twenty roaming partners is maintaining twenty separate technical connections, twenty commercial agreements, and twenty reconciliation processes. A roaming hub collapses all of that into a single connection point: connect once, reach every participant on the hub.

The major European roaming hubs — Hubject, Gireve, and e-clearing.net — grew out of this problem in the 2013 to 2016 period, initially using proprietary protocols before the industry converged on OCPI as the common data standard. By 2025, even Hubject, which had long operated its own OICP protocol, had formally adopted OCPI — a signal that the industry had settled on a single technical language for B2B session data exchange.

What a Charging App Actually Does

A charging app — whether a standalone CPO app, an aggregator app, or a white-label product offered by an eMSP — has one job from the driver's perspective: make charging simple. It shows available stations, displays pricing, starts the session, handles payment, and provides a receipt. For drivers, this is the entire user experience of public charging.

From a CPO's perspective, the charging app represents the driver-facing layer of their own eMSP function. If a CPO operates its own app, it is acting as both infrastructure operator and mobility service provider simultaneously. That is common, particularly among larger networks that have the resources to build and maintain both layers.

From a Demand Partner's perspective, the charging app is the product. A fleet platform, a mobility app, or an OEM offering in-car charging services is, in practice, providing a charging app experience embedded in a broader product. The driver does not leave their platform to charge. The charging experience is native.

What the charging app cannot do by itself is give the driver access to chargers that sit outside the CPO's own infrastructure. A CPO app that only shows that CPO's chargers is useful where that CPO operates. It is useless everywhere else. The solution to this limitation is roaming — and roaming, at scale, requires a hub.

What a Roaming Hub Actually Does

A roaming hub is a B2B infrastructure layer. Drivers do not interact with it directly and, in the normal course of events, are unaware it exists. It operates between CPOs and Demand Partners, facilitating the three things that a charging session requires beyond the physical act of delivering electricity: authentication, session data exchange, and financial settlement.

When a driver using a Demand Partner's app initiates a session on a CPO's charger, several things need to happen in the background almost instantaneously. The CPO's back-end needs to verify that this driver is authorised to charge, which requires communicating with the Demand Partner's system. The session data — start time, energy consumed, location, tariff — needs to flow from the CPO's infrastructure to the Demand Partner's platform so that the driver can be billed correctly. And the revenue from that session needs to be allocated and eventually settled between the CPO and the Demand Partner.

In a bilateral world, every one of those steps requires a pre-existing direct connection between the specific CPO and the specific Demand Partner. A roaming hub removes that requirement. Both parties connect once to the hub. The hub authenticates, routes session data, and manages the settlement layer between all participants. One integration, thousands of possible counterparties.

The commercial logic is identical to what Visa and Mastercard built for card payments, or what the GSM Association built for international mobile roaming. No merchant needs a direct agreement with every card-issuing bank. No mobile subscriber needs a separate contract with every foreign carrier. The clearing infrastructure sits in the middle and makes the market work.

The Key Differences, Plainly Stated

The charging app vs roaming hub distinction differs across every meaningful dimension.

The charging app is consumer-facing. The roaming hub is B2B infrastructure. The charging app manages the driver relationship — identity, preference, payment method, session history. The roaming hub manages the operator relationship — authorisation tokens, session CDRs (charge detail records), commercial agreements, and financial flows.

The charging app is a product that can be built, white-labelled, or embedded. The roaming hub is a shared service that participants connect to rather than build. A CPO does not build its own roaming hub any more than a merchant builds its own card network. Both are joining infrastructure that already exists and that derives its value from network effects — the more participants, the more useful it is for all of them.

For CPOs, the practical implication is clear. Building or partnering with a charging app addresses the question of how your own drivers interact with your network. Connecting to a roaming hub addresses the question of how drivers from other networks reach your chargers at all. The former affects the direct customer experience. The latter affects utilisation.

For Demand Partners, the implication is equally clear. Providing a good charging app experience requires access to chargers beyond any single CPO's network. That access comes through roaming. And roaming at scale — without the overhead of bilateral agreements with every CPO you want to reach — requires a hub or a network layer that performs the same function.

Why This Distinction Matters Now

The distinction between a charging app vs roaming hub has always existed in principle. It matters more now for two reasons.

The first is regulatory. The EU's Alternative Fuels Infrastructure Regulation requires price transparency and ad-hoc payment access across public charging networks. Meeting those requirements involves both the app layer — drivers must be able to see and pay the correct price — and the hub layer — that price must be transmitted accurately between the CPO and whatever platform the driver is using. The two layers must work together. A technically correct roaming integration with a broken pricing transmission still produces a regulatory compliance problem.

The second is commercial maturity. As the EV charging market grows, the economics of bilateral roaming — one contract, one technical integration, one reconciliation process per counterparty — become increasingly untenable for both CPOs and Demand Partners. The hub model scales. The bilateral model does not. The operators who understand this early are the ones building on infrastructure that will still work at ten times their current volume.

Understanding the charging app vs roaming hub distinction is essential for any organisation planning its EV charging strategy — whether building a consumer product or connecting to market infrastructure.

NetworkCore connects Demand Partners with CPO networks through one API, handling session routing and control, payment capture, revenue sharing, and settlement automatically. For Demand Partners looking to embed charging access without the overhead of managing roaming relationships individually, and for CPOs looking to diversify their demand channels without bespoke integrations per partner, this is precisely the layer that sits between the charging app and the market — and makes both work at scale.