Which backend should OEMs ship with their chargers

A charger manufacturer's product decisions do not stop at the hardware. The moment a charger leaves the factory, someone has to answer three questions: how does an installer configure and monitor it, how does the end-user start a session and see what it cost, and how does it talk to anything else, an energy management system, a fleet tool, a billing platform. Get the backend wrong and all three answers involve either building software the company is not set up to maintain, or picking a platform that locks the brand to one vendor's roadmap.

The three things buyers actually ask for

In practice, an OEM shipping a charger needs a CSMS to manage it, an app or portal so the people using it are not stuck reading a manual, and a way for outside software to connect. Plugchoice's OEM program packages exactly that: a CSMS that can carry the OEM's brand, a driver and installer app that runs on OCPP rather than a proprietary protocol, and a public REST API underneath. The white-label parts run under a separate agreement.

The white-label part is not cosmetic. The web portal, the branded emails and the mobile app can carry the OEM's logo, colors and domain. White-labeling, the branded emails, a custom domain and a branded app are available under a separate agreement.

Why "runs on OCPP" is the part that matters

The distinction that actually protects an OEM is not that the app looks branded, it is what protocol sits underneath it. An app built against a single backend's proprietary API stops working the day that backend changes, whether because the OEM switches platforms, a customer wants to run a different back office, or a reseller needs the charger to sit on infrastructure the OEM does not control. An app built on OCPP keeps controlling the charger regardless of which back office is behind it, because Plugchoice's OCPP proxy can route a charger's messages to an existing backoffice without replacing it. A customer's current setup keeps working while the OEM's own app and portal run alongside it.

What ships under the hood

Past the app and portal, Plugchoice can set up an OEM side for managing a fleet across product lines, under a separate agreement: feature flags to enable or disable capabilities per charger model, virtual products so a new charger model inherits the right default configuration automatically, and firmware lifecycle tools, fleet-wide version tracking, staged rollouts to a test group before a wider push, and remote updates without a site visit. Firmware management and remote configuration are part of the platform today. None of it requires the OEM's own engineering team to build or maintain a device management backend from scratch.

Two commercial models

Plugchoice's OEM program can run on two commercial models, set in a signed agreement, and the choice affects who owns the customer relationship. Under the free model, the OEM offers Plugchoice to its customers at no upfront cost, and customers pay for the paid features they activate, such as Smart Charging. Under the OEM-managed model, the OEM keeps the full customer relationship and pricing control, and pays Plugchoice a recurring per-charger platform fee instead. White-labeling is available under either model, in that agreement. Neither model requires exclusivity: the OCPP proxy means a charger can run through the OEM's branded layer while still connecting into whatever back office the end customer already uses.

Building on top of it

For OEMs or their integration partners who want to connect their own tools rather than rely on the portal and app alone, the same system exposes a public REST API: personal access tokens for quick integrations and internal tools, OAuth 2.0 for production applications that need scoped, delegated access. The API returns data in the same format across charger brands, as far as each charger reports it: chargers, sessions, meter values, configuration, so an OEM's own dashboards or a customer's energy management system do not need separate logic for every hardware variant on the fleet.

Which model an OEM should pick depends on how much of the customer relationship it wants to own and how much platform risk it is willing to carry itself. What does not change across that decision is the protocol underneath: an app and backend built on OCPP is the one choice that does not have to be revisited every time a customer, a market, or a backend requirement changes.