A country can have more chargers and still have a fragmented network
Charging infrastructure is usually counted as physical units: sites, connectors and kilowatts. Those numbers matter, but a driver experiences a network rather than a count. If every operator requires a different application, account, wallet and integration, the market can accumulate hardware while remaining operationally fragmented.
For fleets the problem is even more obvious. A logistics company may charge primarily at its depot but still need public or partner-network access when vehicles leave their normal routes. An e-mobility service provider may want to show chargers owned by several charge point operators. A roaming hub may sit between many parties. Without a common exchange contract, each new relationship becomes a custom integration.
Custom integrations are not always wrong. Early pilots often move faster with them. The problem appears when the market grows and every bilateral connection has different field names, authentication, tariff semantics, status codes and settlement assumptions. The cost of integration begins to rise faster than the number of useful network relationships.
Do not confuse the charging protocol layers
EV charging has several protocol boundaries, and they solve different problems. OCPP is commonly used between a charge point and a charging management system. OCPI sits at a market-party boundary, such as between a Charge Point Operator and an eMobility Service Provider. ISO 15118 addresses communication between the vehicle and charging infrastructure for capabilities including Plug & Charge. Treating these as interchangeable leads to poor architecture.
A charger can speak OCPP perfectly and still be invisible to an external mobility provider. A roaming relationship can exchange OCPI data while the underlying station uses a different device protocol internally. The system should define these seams intentionally so hardware, backend operations and market interoperability can evolve independently.
This separation is strategically useful in young markets. An operator can replace a charger-management backend without forcing every roaming partner to rebuild its integration, provided the external OCPI contract remains stable. Likewise, an eMSP can aggregate locations from several operators without caring about each operator’s internal charger vendor.
OCPI standardizes the market conversation
The EVRoaming Foundation describes OCPI as a protocol for connections between eMobility Service Providers, which have drivers as customers, and Charge Point Operators, which manage charging stations. The current published version is OCPI 2.3.0. Its modules cover the kinds of data that make roaming practical: locations, credentials, tokens, tariffs, sessions, charge detail records, commands and related capabilities.
That matters because discovery is only the first step. A mobility application needs to know where the station is, which EVSE and connector are available, what the tariff means, whether a token is authorized, when a session starts, how much energy was delivered and what final charge detail record should be used for settlement.
When those concepts are standardized, the integration becomes less about translating arbitrary vendor payloads and more about implementing one domain model correctly. It does not remove commercial negotiation or operational exceptions, but it gives the parties a shared technical language.
Stable identifiers become infrastructure
Interoperability depends on identity. Locations, EVSEs, connectors, tokens, sessions and CDRs need stable references across systems. If an operator changes an internal database ID every time a record is migrated, external partners cannot reliably correlate updates. If two systems interpret the same station hierarchy differently, availability and billing can drift.
This is why identifier governance deserves the same seriousness as APIs. Decide who owns each identifier, whether it can change, how retired hardware is represented and how references survive migrations. Keep internal primary keys separate from public protocol identifiers when that reduces coupling.
Versioning matters too. A partner should be able to replay or request data without causing duplicate sessions or CDRs. Update semantics need timestamps and deterministic keys. The broader distributed-systems lessons are familiar: idempotency, durable references and reconciliation are as relevant to charging networks as they are to payments.
Interoperability is also a commercial agreement
A protocol can tell two companies how to exchange a tariff. It cannot decide what the tariff should be, who bears failed-session risk, how often settlement occurs or how disputes are resolved. Roaming therefore sits at the intersection of software and commercial operations.
Before production, parties should agree on service levels, data freshness, invoice cadence, tax treatment, currency, dispute windows, refund handling and responsibility when station status is wrong. The technical contract should map cleanly to those commercial rules. If the backend cannot explain which tariff version produced a CDR, finance teams will eventually be forced to reconstruct it manually.
Testing should include more than successful charging. Simulate stale availability, rejected tokens, interrupted sessions, remote-start failures, changed tariffs and duplicate records. A roaming integration is mature when both parties know how exceptions become support and settlement workflows.
African markets benefit from deciding this early
Many African charging markets are still early enough that fragmentation is not irreversible. That is an advantage. Networks can choose open external contracts before proprietary assumptions become embedded in hundreds of sites and applications.
The continent will not develop as one uniform market. Fleet depots, public hubs, workplace charging, bus systems, motorcycle ecosystems and cross-border corridors will mature at different speeds. That makes interoperability more valuable, not less. A driver or fleet should be able to use infrastructure outside the operator that originally onboarded them, while the underlying businesses retain their own brands and commercial models.
Open roaming also creates room for aggregators and specialized eMSPs. A company can focus on fleet routing, payments, energy optimization or driver experience without owning every charger it exposes. Charge point operators can focus on sites and uptime while making capacity discoverable through standardized interfaces.
Implement interoperability before the network is too large to change cheaply
The right time to introduce a clean protocol boundary is before dozens of internal services and partner applications depend on proprietary payloads. Start by mapping the operator’s own domain model to OCPI concepts. Decide which system is authoritative for locations, status, tariffs, tokens, sessions and CDRs. Build a versioned adapter rather than leaking internal database tables directly to partners.
Credentials and party roles need careful handling. Incoming requests should be authenticated and scoped to the correct partner. Outbound queues need retry and idempotency. Large location catalogs should be paginated. Session and CDR processing should preserve partner references. Monitoring should show which party is failing and at which protocol module.
Run conformance and partner tests against realistic data. The EVRoaming Foundation publishes OCPI material and tools, including OpenAPI documentation and migration guidance for 2.3.0. Use those resources rather than implementing from a blog summary or an old example payload.
The goal is a useful network effect, not protocol compliance for its own sake
Interoperability is valuable when it makes charging easier to discover, use and operate. A technically compliant API that publishes stale status or incorrect tariffs does not create a good network. Operators still need reliable hardware, accurate backend state, support processes and commercial settlement.
But open contracts make those investments composable. One charging site can become useful to more drivers. One fleet platform can route across more operators. One eMSP can enter a city without negotiating a bespoke payload format with every CPO. The software layer turns separate pieces of infrastructure into a broader service network.
Africa needs more chargers, especially where real vehicle demand can sustain them. It also needs those chargers to participate in systems larger than themselves. If interoperability is designed early, the market can scale through connection rather than through a collection of isolated apps and charging islands.
Sources and further reading
