OCPP, Billing, and Other Essentials of a Charging Station App Architecture

Quick answer:

The architecture of an EV charging station application is built around three core layers: the charging station exchanges data with the Central Management System (CSMS) using the OCPP protocol, the CSMS sends real-time status updates to the mobile application, and the billing system calculates charging costs based on meter readings. OCPP is an open standard, but in practice every hardware manufacturer requires its own adapter layer. Below are the eight essential components without which this architecture cannot operate reliably.

1. Station Communication: OCPP and Version Selection
OCPP (Open Charge Point Protocol) is the standard for communication between a charging station (Charge Point) and the Central Management System (CSMS). As of 2026, most deployed charging stations run OCPP 1.6 (typically OCPP 1.6J using JSON over WebSocket) because it is simpler and less expensive to implement. OCPP 2.0.1 is rapidly gaining adoption in new commercial deployments and public fast-charging networks thanks to its enhanced security features and Smart Charging capabilities. OCPP 2.1, which introduces support for Vehicle-to-Grid (V2G) and Plug & Charge, is still relatively uncommon but demand is growing as bidirectional charging becomes more widespread. A modern architecture should support at least OCPP 1.6 and OCPP 2.0.1 simultaneously, since migrating an entire charging network to a single protocol version typically takes years.

2. Central Management System (CSMS)
The CSMS accepts WebSocket connections from charging stations and processes the protocol's core messages, including BootNotification (station startup), StatusNotification (connector status such as Available, Occupied, or Faulted), Authorize (user authorization), StartTransaction and StopTransaction (charging session start and end), and MeterValues (meter readings collected during charging). It serves as the central hub through which all events pass before reaching the billing platform or the mobile application.

3. Hardware Vendor Adapter Layer
Although OCPP is a standard, it does not guarantee plug-and-play compatibility across different manufacturers. In our experience, integrating charging stations from Chinese manufacturers alongside European CircControl hardware required a dedicated adapter layer. Each vendor implements custom protocol extensions, uses non-standard message fields, and handles errors differently. The adapter layer normalizes data from every manufacturer into a unified internal model before forwarding it to the billing system and mobile application.

4. Billing Engine
The billing engine receives MeterValues (consumed kWh) and calculates the final charging cost based on actual energy consumption rather than estimates. The pricing logic typically includes separate tariffs for AC and DC connectors, as well as an idle fee that applies when a vehicle remains connected after charging has finished. For B2B customers, the billing platform should also support spending limits per employee or vehicle and provide consolidated reporting across departments.

5. Payment Layer
The payment layer operates using an account balance model: users add funds to their in-app balance, and charging costs are deducted according to actual usage without requiring card pre-authorization for every charging session. Card pre-authorization is only needed in scenarios where no mobile application is used and the charging station includes an integrated payment terminal. In that case, the terminal temporarily reserves funds, and after StopTransaction and the final meter reading are received, it charges the actual amount and releases any remaining balance. In both scenarios, payment processing should be asynchronous so that delays between the end of charging and the final MeterValues message do not negatively affect the user experience.

6. Client API and Push Notifications
The mobile application receives charging station status updates and session information through the API rather than communicating directly with the CSMS. Push notifications for charging start, charging completion, and error events are generated from the same OCPP events (StatusNotification, StopTransaction) that the CSMS processes for billing. This approach eliminates inconsistencies between the mobile app and the actual charging station status.

7. Operator Dashboard
Network operators require a dedicated dashboard that provides real-time visibility into every charging station's status, revenue, charging session history, and system incidents. Whenever a station enters the Faulted state or experiences a failure, the notification system should immediately alert the operator via push notifications, email, or integration with internal communication platforms—not simply display the issue on a dashboard that may not be monitored continuously.

8. Queues and Fault Tolerance
A charging station may lose its internet connection while a charging session is in progress. In such cases, it should continue charging locally and synchronize session data (MeterValues, StopTransaction) once connectivity is restored. The architecture must process delayed or duplicate messages idempotently. For example, if StopTransaction is received twice due to a network issue, the billing system must ensure that the customer is not charged twice.

ilab.md designs and develops software architectures for EV charging stations—from OCPP-based hardware integration, including Chinese manufacturers and CircControl equipment, to billing platforms and React Native mobile applications. This expertise is applied not only in Moldova but also in international markets.

Sources for OCPP version information: chargelab.co, lembergsolutions.com, codibly.com.