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 free white-label CSMS, a driver and installer app that runs on OCPP rather than a proprietary protocol, and a public REST API underneath, all under the OEM's own brand rather than Plugchoice's.
The white-label part is not cosmetic. The web portal, the branded emails, and the mobile app all carry the OEM's logo, colors, and domain, set from the portal's own team settings rather than through a project with Plugchoice's team. A white-label mobile app is the one piece that needs a separate agreement rather than coming with every plan; the portal, email, and one custom domain do not.
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, the OEM side of the platform is where a manufacturer actually manages a fleet across product lines: 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. None of it requires the OEM's own engineering team to build or maintain a device management backend from scratch.
Two ways to make money on it
Plugchoice's OEM program runs on two different commercial models, 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 Plugchoice earns a revenue share when a customer activates a paid feature, 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; only the branded mobile app needs its own agreement, as above. 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 the same normalized data regardless of charger brand or firmware, 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.
