Buying the wrong charger rarely fails on the power side first. It fails on the software side later, when you try to configure it remotely, balance loads across a site, push a firmware update, read useful meter data, or connect it cleanly to the backend you already promised your customer.
Most EV chargers today say "OCPP supported" somewhere on the spec sheet. That is a good start, but it is not the whole story. Two chargers can both claim OCPP support and still differ wildly in what you can actually read, change, update and control from your software stack. The real question is not "Does this charger support OCPP?" but: how much of this charger can software actually reach?
This article is a practical checklist. If you install chargers for a living, it should help you ask better questions before you buy, avoid nasty surprises after commissioning, and spend less time driving back to site for things that should have been handled remotely.
Why software compatibility matters more than the spec sheet suggests
OCPP gives chargers and central systems a standardized communication layer. That is genuinely useful. But OCPP does not guarantee that every charger implements every feature the same way, to the same depth, or with the same level of remote access.
OCPP 1.6 is still common and still useful. OCPP 2.0.1 adds better device management, security and richer feature support, but it is not a magic fix by itself. What matters is version plus implementation depth together. A well-implemented 1.6 charger can be more practical to manage than a poorly implemented 2.0.1 one.
The gap between "checkbox OCPP" and "genuinely software-compatible" is where installers get burned. It shows up in callbacks, return visits, workarounds, and that familiar frustration: "this only works in the vendor portal."
An OCPP backoffice can only work with what the charger actually exposes. If important settings, measurements or controls are locked behind a manufacturer app or a local web UI, your backend cannot help you, no matter how good it is.
What installers should check before buying
Here is what to actually verify. Treat it as a buying checklist.
1. OCPP version and implementation depth
Ask which OCPP version the charger supports, exactly. Then ask which feature profiles (1.6) or functional blocks (2.0.1) are implemented. "OCPP supported" without specifics is a yellow flag.
A charger might support Core and FirmwareManagement but skip SmartCharging or LocalAuthListManagement. That matters. The Open Charge Alliance publishes what each profile and block covers, so you can check what the charger claims against what you actually need.
2. Remote configuration coverage
This is the big one. How much of the charger can be read or changed remotely from the CSMS, without a vendor portal, a local visit, or a proprietary tool?
Installers care about remotely managing: charge-point identifiers, backend URL and communication settings, current limits, meter sampling intervals, smart-charging parameters, power recovery behavior after outages, phase-related settings, authorization behavior, reboot and reset behavior, and diagnostics logging.
If any of those require the vendor app or a local web UI, you need to know before you commit. A good web portal can only configure what the charger lets it configure.
3. Firmware update support
Firmware deserves its own checkbox. Version-specific bugs exist. Partial OCPP support sometimes depends on a specific firmware branch. Update procedures can be manual-only or vendor-specific. And backend-triggered firmware updates do not always match what the charger actually supports.
A charger that is software-compatible only on specific firmware branches is not the same thing as a charger that is software-compatible by design. Check how updates work, how status is reported, and whether the process is documented. Some vendors publish clear implementation guides (like ABB's OCPP implementation overview); others leave you guessing.
4. Diagnostics and fault visibility
When something goes wrong on site, how much can you see remotely? Can you pull diagnostics logs? Are fault codes meaningful or generic? Does the charger report status changes clearly enough for first-line support to triage without a site visit?
Good diagnostics visibility is the difference between "the charger is offline, somebody go check" and "the charger reported a ground fault at connector 1 at 14:32, here is the context."
5. Meter access and measurands
"Meter data" can mean very different things depending on the charger:
- Basic session totals (energy delivered per session)
- Operational telemetry (voltage, current, power, per phase)
- Load balancing inputs (real-time power readings the backend can act on)
- Reimbursement data (accurate enough for cost sharing)
- Billing-grade evidence (signed meter values where regulations require them)
Verify which measurands are exposed, at what intervals, whether data is per phase, whether values are clock-aligned, and whether signed meter values are available where needed. If your use case involves power management or solar-aware charging, you need real-time per-phase data, not just session totals.
6. Phase switching support
A charger may support "smart charging" on the brochure but still not support the exact phase behavior needed on site. Phase switching matters especially for solar-aware charging and low-surplus scenarios where you want to drop from three-phase to single-phase to keep charging instead of pausing.
Treat this as its own topic, not just a subpoint of load balancing. Ask specifically: does this charger support dynamic phase switching? Under which firmware version? Through which interface?
7. Load-balancing hooks
"Load balancing" on a brochure is not the same thing as load-balancing hooks your software stack can actually use.
There is a real difference between:
- Native vendor load balancing (only within the vendor's own ecosystem)
- Local cluster balancing (a few chargers sharing a circuit)
- Broader site-level dynamic load balancing
- Meter-driven site balancing
- Solar-aware charging
- External EMS or CSMS-driven control via dynamic power sharing
If you need your backend or energy management system to set charging profiles dynamically, make sure the charger actually accepts external smart-charging profiles and does not only respond to its own vendor controller.
8. Vendor parameter exposure
A charger may technically support OCPP while still locking important behavior inside a manufacturer app, a vendor-only installer portal, a local web UI, or a hidden configuration tool.
Relevant parameters to check: current limit, meter intervals, outage recovery behavior, authorization mode, phase mapping, maximum profiles installed, backend URL, websocket transport mode, reset behavior, and firmware or diagnostics status. Vendors like Bender and Alfen publish their OCPP parameter references openly. That transparency is a good sign.
9. Real commissioning inputs required
Before a charger talks to your backend, it needs to be set up with the right connection details. Verify what the commissioning process actually looks like: does the charger need a ChargePoint ID, a backend URL, a security profile, certificates, or passwords?
How are those entered? Through a QR code, the vendor app, a local web UI, or NFC? Can you connect the charger to your platform quickly, or does it require a multi-step vendor-specific process?
A smooth commissioning flow saves real time per install. A painful one adds up fast across a fleet.
10. Fallback behavior when software and charger disagree
What happens when the charger loses connection to the backend? When a smart-charging profile expires or conflicts? When the charger reboots mid-session?
Some chargers fall back gracefully to a safe default (like charging at reduced power). Others stop entirely. Others ignore the last profile and charge at full power, which can trip breakers on a shared site. Know what happens in the gap.
Red flags to watch for
Be cautious if you encounter any of these:
- "OCPP supported" but no public implementation guide or configuration-key list
- No clear statement on which feature profiles or functional blocks are supported
- Remote configuration only partly exposed, with key settings locked in the vendor portal
- Firmware update process undocumented or manual-only
- Meter values available, but only session totals
- No clarity on phase switching behavior or conditions
- Load balancing available, but only within the vendor's own ecosystem
- Important settings accessible only through a proprietary installer tool
- Software compatibility depends on a specific firmware branch
- No evidence of successful interoperability testing with your intended backend
Questions to ask your charger vendor before buying
Keep these handy. They save pain later.
- 2.Which OCPP version is supported, exactly?
- 4.Which OCPP feature profiles or functional blocks are supported?
- 6.Which charger settings can be changed remotely from the CSMS?
- 8.Which settings still require the vendor app, portal, or local tool?
- 10.Can firmware be updated remotely, and how is status reported?
- 12.Which meter measurands are exposed, at what intervals, and per phase or not?
- 14.Are signed meter values available where needed?
- 16.Does the charger support dynamic phase switching, and under which firmware or conditions?
- 18.Which load-balancing modes are supported: native, local cluster, external EMS, CSMS-driven?
- 20.Which parameters are readable and writable over OCPP versus vendor-private?
- 22.Is there a public implementation guide or configuration-key list?
- 24.Has this charger and backend combination passed known interoperability tests?
Make better buying decisions
Installers do not just buy hardware. They inherit its software behavior. The ugly surprises usually show up after commissioning, not before, and they show up as callbacks, workarounds, and limitations that were never in the brochure.
Check software compatibility the way you check electrical specs: before you commit. Ask the specific questions. Read the implementation guide if there is one. And if a vendor cannot answer these questions clearly, that tells you something too.
If you want a platform that actually uses the depth of what a well-implemented charger exposes, take a look at what Plugchoice offers for installers, or check the developer documentation if you are building integrations yourself.