EV Charging Station Software vs. Network Provider: Who Does What, and Who Owns Uptime?

A site host may buy chargers from one company, run them on EV charging station software from another, process payments through a third party, connect through a cellular carrier, and rely on a local electrician for repairs. When a charger goes offline, each provider can point at a different layer of the system. The driver just sees a broken plug.

Part of the confusion is language. “EV charging station software,” “EV charging network provider,” and “charge point operator” (CPO) are often used as if they are the same thing. They are not. One is a software layer. One is a business model that may or may not include that software. One is an operating role. Understanding the difference is the difference between knowing who to call when a charger fails and being passed around a chain of vendors.

This guide defines EV charging station software precisely, explains what an EV charging network provider actually does, maps the full operating stack, and answers the question that matters most for procurement and renewals: who owns uptime, and who owns the data. It is written to be useful first. Epic Charging appears near the end, in context.

EV charging station software is the digital operating layer that monitors and controls charging stations, while an EV charging network provider is the business that delivers charging service and may bundle that software with hardware, payments, connectivity, and maintenance, which is why uptime is a shared outcome rather than the job of one vendor.

EV charging station software is the cloud platform operators use to monitor, configure, control, price, and report on EV charging stations. It connects to each charger, usually over the Open Charge Point Protocol (OCPP), collects status and session data, enforces access and pricing rules, and produces operational reporting. It turns a standalone charger into a managed, billable, monitored endpoint.

The industry gives this layer several names. A Charge Point Management System (CPMS) and a Charging Station Management System (CSMS) describe the same category: the back-end software that manages charging stations. CPMS is the older term associated with OCPP 1.6. CSMS is the wording used in OCPP 2.0.1. The change tracks the protocol’s evolution, not a difference in function. “EV charging backend,” “EV charging software platform,” and “charge point management system” all point at the same layer.

What EV charging station software typically does:

• Charger monitoring: live status for each connector, fault detection, and alerts.
• Session management: start, stop, and record charging sessions.
• Remote controls: reset a charger, unlock a connector, push a configuration change.
• Access control: RFID, app, and role-based rules that separate public users, residents, employees, and fleet drivers.
• Pricing: per kWh, per session, per time, idle fees, and member vs. guest rates.
• Payments integration: connecting sessions to a payment processor and, where supported, to card readers on the charger.
• Load management: distributing available power across active chargers to stay within a site’s electrical capacity.
• Reporting and analytics: usage, revenue, energy, and uptime data, exportable for finance and utility reporting.
• Firmware and OCPP tools: managing firmware and protocol configuration across mixed hardware.
• Ticketing and alerts: flagging faults and, in some setups, routing them to a support or dispatch workflow.
• APIs and integrations: connecting charging data to CRM, ERP, billing, and telematics systems.
• Driver-facing functionality: in some platforms, an app or web flow for finding, starting, and paying for a session.

What EV charging station software does not automatically include: the physical charger, the electrical installation, the cellular connection, utility power, hardware warranty coverage, or a technician in a truck. Software can see and often diagnose a problem. Resolving a physical problem requires a physical party. Whether that party is part of your software provider’s offering depends entirely on the contract.

An EV charging network provider is a business that delivers EV charging as an operational service. Depending on its model, it may provide only the software layer, or it may also coordinate hardware, connectivity, payments, driver services, maintenance, and network operations. The term describes a commercial role, not a fixed scope.

The label “network provider” hides at least five different business models:

1. Software-only platform provider. Supplies the CPMS or CSMS. The customer owns the hardware and arranges installation, connectivity, and maintenance separately. Hardware-agnostic and OCPP-based platforms usually sit here.
2. Managed network provider. Supplies the software and also coordinates operations: monitoring, support, and sometimes maintenance dispatch, often across third-party hardware.
3. Vertically integrated provider. Sells its own hardware, its own software, its own driver app, and its own support as a single bundle. Convenient, but often the most locked-in.
4. Charge point operator (CPO). The entity that operates chargers, on its own or a customer’s behalf, and is typically the party responsible for keeping them available. A CPO uses a CPMS; it is not itself the software.
5. White-label network provider. Supplies the software and operations under the customer’s brand, so the end product looks like the customer’s own network.

The practical takeaway: two companies can both call themselves an “EV charging network provider” and deliver very different things. One might hand you a login and nothing else. Another might own every layer from the concrete to the driver app. Before choosing or renewing, inspect the actual scope of service rather than the label on the website.

The comparison below shows typical roles. The exact scope always depends on the contract.

The pattern: software is a defined layer with a fairly stable role. “Network provider” is a commercial wrapper whose contents change from vendor to vendor. This is exactly why buyers should read the statement of work, not the homepage.

A working charging site is a stack of layers, each owned or operated by a potentially different party. The table below maps who typically owns each layer, what they are responsible for, how directly they influence uptime, and how they tend to fail.

Difference Between EV Charging Station Software and an EV Charging Network

How the layers communicate: the charger runs firmware and connects over cellular or wired internet to the CPMS or CSMS using OCPP. The software authorizes drivers, applies pricing, records the session, and passes payment data to a processor. If the site participates in roaming, an OCPI link lets outside drivers charge. The software can see and often diagnose a fault at almost any layer, but it can only act directly on the layers it controls (authorization, pricing, remote reset, configuration). Everything physical (power, hardware, connectivity, repairs) depends on the party that owns that layer.

No single party controls EV charger uptime. It is a shared outcome. The charge point operator is usually the party contractually responsible for availability, but technical control is split across the hardware manufacturer, the software or CPMS provider, the connectivity carrier, the utility, the maintenance provider, and the site host. Software can detect and diagnose most failures. It cannot physically repair them.

To see why, separate the main failure domains. For each, notice the gap between who can detect a problem and who can resolve it.

Hardware failures
Examples: connector damage, power module failure, screen failure, internal component faults, contactor problems, physical damage. The software can usually detect and often diagnose these remotely. Resolving them requires a technician and often a replacement part from the hardware manufacturer. Detection and repair are two different parties.

Firmware and protocol failures
Examples: failed firmware updates, OCPP communication problems, configuration mismatches, vendor-specific protocol implementation quirks. The software provider can often diagnose and sometimes fix these remotely, but only within what the hardware’s firmware actually supports. “OCPP-compliant” does not guarantee that every function works identically across every OEM.

Connectivity failures
Examples: cellular signal loss, SIM issues, router failure, Ethernet or Wi-Fi interruption, firewall misconfiguration. When connectivity drops, the charger may still deliver power locally but disappears from the software’s view, which is one reason reported uptime and real uptime diverge. Whoever provides the connection owns the fix, and that is frequently not the software provider.

Site and utility power failures
Examples: breaker trips, electrical panel problems, utility outages, insufficient site capacity. These sit with the site host, the electrical contractor, and the utility. Software can flag that a charger lost power. It cannot restore it.

Software and backend failures
Examples: platform outage, authorization failure, incorrect pricing configuration, session-data errors, API or payment integration failure. This is the domain the software provider directly controls and is accountable for. It is also usually the fastest to resolve, because it is fixed remotely.

Operations and maintenance failures
Examples: an alert that no one acts on, delayed dispatch, spare-part delays, a weak escalation process, no clear owner for the ticket. This is often where uptime is actually lost. The fault may be minor, but if no party is clearly responsible for acting on the alert, the charger stays down.

The distinction to hold onto: monitoring an issue (seeing it), diagnosing an issue (identifying the cause), remotely resolving an issue (fixing it through software), physically repairing an issue (sending a person), and being contractually accountable for the service level (owing a remedy) are five separate things. A provider can do the first three and still owe you nothing for the last two if those responsibilities were never in the contract.

Technical influence and contractual accountability are not the same. The party that can see a fault first is often not the party that promised you a number. Contractual uptime lives in the service-level agreement (SLA) and the definitions around it, so read those closely.

Terms that determine what an uptime commitment is actually worth:

• Availability definition: what counts as “up,” and whether it is measured per connector, per port, per charger, or per network.
• Planned vs. unplanned downtime: whether scheduled maintenance is excluded from the calculation.
• Exclusions: events outside the operator’s control, such as utility outages, vandalism, natural disasters, and limited operating hours, are commonly excluded. As a reference point, the U.S. federal NEVI program requires each port to average more than 97% annual uptime and excludes outages outside the operator’s control from that calculation (23 CFR Part 680; see sources).
• Response time vs. resolution time: how fast someone acknowledges a fault vs. how fast it is actually fixed. These are very different promises.
• Remote resolution vs. field dispatch: what the provider fixes remotely vs. what triggers a truck roll, and who pays for it.
• Hardware warranty: whether failed parts are covered, by whom, and for how long.
• Connectivity responsibility: who owns the SIM or connection and its failures.
• Reporting methodology: who calculates the uptime number and whether you can see the underlying data.
• Escalation ownership: who is the single accountable owner when a ticket stalls.

Questions to Ask Before Accepting an Uptime Guarantee

• How is uptime calculated, and by whom?
• Is it measured by charger, port, connector, or network?
• What events are excluded from the calculation?
• Who monitors for failures, and how quickly?
• Who opens the ticket when a charger goes down?
• Who contacts the hardware manufacturer for a warranty repair?
• Who dispatches a technician, and how fast?
• Who pays for labor and replacement parts?
• What happens to the SLA when connectivity fails?
• Are response and resolution times contractually defined, not just aspirational?
• Can the site host see the raw uptime data, not only a summary?
• Is there a service credit or other remedy when the number is missed?

If a provider cannot answer these clearly, the uptime number on the proposal is marketing, not a commitment.

There is no universal answer to who owns EV charging data. It depends on the contract, the data-processing agreement, and how the system is architected. This section is informational and not legal advice.

Different data types often follow different rules:

• Charger telemetry: status, faults, and energy readings from the hardware.
• Session data: start, stop, duration, energy delivered, and location per charge.
• Driver account data: identities and credentials of the people charging.
• Payment data: transaction and settlement records, often held by a payment processor under its own compliance rules.
• Pricing data: the tariffs and rules an operator configures.
• Energy data: consumption used for utility and sustainability reporting.
• Maintenance records: fault and repair history.
• Site-performance data: uptime, utilization, and revenue by site.
• Aggregated or anonymized data: whether the provider may reuse pooled data across customers.

The roles that appear in these arrangements can include a data owner, a data controller, a data processor, the system operator running the software, the payment processor, and the site host. Which party plays which role is a contract question, not a default. In particular, the party that operates the software is not automatically the owner of the data flowing through it, and the party that processes payments does not automatically own the charging data.

Data questions to put in the contract

• Can the customer export its data, and in what formats?
• How frequently can it be exported?
• Who retains historical records, and for how long?
• What happens to the data after the contract ends?
• Can the provider use aggregated or anonymized data, and for what?
• Who controls the driver relationship?
• Can the data be migrated to another platform?
• Are documented APIs available for access?
• Are there additional fees to extract your own data?

Myth: The software provider owns every part of uptime. Reality: Software owns the backend layer and can detect faults across the stack, but it cannot restore grid power, repair hardware, or fix connectivity it does not provide. Uptime is shared.

Myth: A network provider always owns the chargers. Reality: Only vertically integrated providers own the hardware. Many “network providers” run on hardware the customer owns.

Myth: OCPP means every charger works perfectly with every platform. Reality: OCPP is a shared protocol that makes interoperability possible, not automatic. Firmware quality and OEM-specific implementations still cause differences. Confirm a provider has actually commissioned your specific charger models.

Myth: Remote monitoring eliminates field maintenance. Reality: Monitoring finds problems faster. It does not replace connectors, contactors, or power modules. Physical failures still need a person on site.

Myth: The company processing payments owns all the charging data. Reality: Payment processing and charging data are separate. Ownership of session, telemetry, and driver data is set by contract, not by who runs the card transaction.

Myth: Changing software always requires replacing the hardware. Reality: With OCPP-based chargers, an operator can often migrate to new EV charging station software without replacing equipment. Closed, proprietary hardware is the exception that can force a swap.

Myth: A 99% uptime promise means every driver succeeds 99% of the time. Reality: SLA uptime often excludes certain outages and may be measured per port rather than per driver session. Reported uptime and the experience at the plug can differ, which independent studies have documented.

Myth: A driver app and a charger-management platform are the same product. Reality: A driver app is the consumer-facing layer for finding and paying. A CPMS or CSMS is the operator-facing layer that controls and monitors the chargers. They can come from the same vendor or different ones.

Evaluate scope and accountability, not adjectives. The strongest signal is a provider that can answer precise operational questions without hedging.

Criteria worth scoring:

• Open-protocol compatibility: genuine OCPP support in both directions (their software runs others’ hardware, and their hardware runs others’ software).
• Hardware validation: a list of charger OEMs and models actually commissioned, ideally including yours.
• Uptime measurement: how “up” is defined and whether you can see the raw data.
• Remote diagnostics: how much they can diagnose and fix without a truck roll.
• Support escalation: defined response and resolution times, and a named accountable owner.
• Field-service coordination: whether maintenance is included, coordinated, or entirely your problem.
• Data portability: export formats, frequency, and any extraction fees.
• Reporting: usage, revenue, energy, and uptime, exportable for finance and utilities.
• Pricing flexibility: per kWh, session, time, idle, and member rates.
• Access model: support for public, private, fleet, and resident access as needed.
• Payment methods: app, RFID, and card readers on the charger where relevant.
• Load management: dynamic (not just static) balancing for high-density and depot sites.
• Cybersecurity: recognized attestations such as SOC 2, role-based access, and audit trails.
• API capabilities: documented APIs for integration.
• Migration support: a defined path to move you on, and off, without stranding hardware.
• Contract transparency: clear renewal and exit conditions, and clear data ownership.

Final Selection Checklist

• Confirmed OCPP support and versions, in both directions
• Named list of commissioned hardware, including your models
• Clear, data-backed uptime definition and reporting
• Defined SLA with response and resolution times and a remedy
• Written scope for maintenance and field dispatch
• Data ownership and export terms in writing, with no extraction fees
• Dynamic load management for your site type
• SOC 2 or equivalent security posture
• Documented migration path on and off the platform
• Transparent renewal and exit terms

Epic Charging is, first and foremost, an EV charging station software provider. It supplies the CPMS/CSMS layer: OCPP-based, hardware-agnostic charger management for operators who do not want to be locked to a single hardware vendor.

Within the software layer, Epic supports remote visibility and controls, configurable access and pricing, driver payments including card readers on chargers, dynamic load management (Charge OptimAIzer), reporting and analytics, and ticketing and operational workflows. Epic works across public, fleet, multifamily, workplace, municipal, and enterprise charging, and it specializes in software-led migrations, including moving sites off discontinued platforms without replacing hardware. Epic provides U.S.-based support and is SOC 2 compliant.

What Epic, as a software provider, does not by itself replace: the electrical installation, utility service, physical hardware repair, on-site field maintenance, third-party connectivity, and hardware warranties. Those layers sit with contractors, utilities, hardware manufacturers, and connectivity carriers. Where Epic adds value on uptime is in the layer it controls, and in the visibility, diagnostics, and ticketing that help the right party act faster on the layers it does not.

If you are evaluating or renewing a provider and want a clear picture of who owns each layer of your specific deployment, Epic can walk through it with you. Contact Epic Charging for an obligation-free review of your stack.