EV Charging Management System for CPO Requirements Guide

An EV charging management system for CPO operations must do more than show chargers on a map. It becomes the operating record for availability, authorization, charging transactions, tariffs, meter data, remote service, energy control, roaming, and often the evidence used by finance and regulators. A weak platform can leave a technically sound charger unavailable, incorrectly priced, or impossible to reconcile.

This guide helps CPO technology, operations, product, finance, and procurement teams build a requirements specification and vendor scorecard. Luxman Energy publishes connected commercial charging options, while the exact backend functions, integrations, hosting model, and service responsibilities should be confirmed for each project.

Define the management system boundary

The charging management system, often called a CSMS or CPMS, normally connects to chargers and coordinates their operation. It may also include or integrate customer accounts, apps, payment orchestration, roaming, energy management, maintenance, and reporting. Buyers should not assume every module comes from one vendor.

Map the systems of record before comparing products:

Data or process	Authoritative system to assign
Physical charger and connector inventory	CSMS, asset management, or both with a controlled master
Live connector state	Charger events interpreted by the CSMS
User and authorization credential	Identity, fleet, eMSP, or CSMS account service
Tariff and effective version	CSMS commercial engine or external pricing service
Charging transaction and meter values	Charger and CSMS transaction records
Card authorization and capture	Payment gateway, PSP, and acquirer
Roaming session and charging data record	CPO platform and roaming interface
Site power limit	Local energy controller, CSMS, or building system
Incident and field work	Ticketing or asset-service platform
Invoice, payout, and general ledger	Billing, ERP, or accounting platform

The same information can be copied into several systems, but one must own creation, change approval, and correction. Otherwise a tariff, connector ID, or terminal mapping can diverge without an alert.

Specify the core asset and device model

The platform should represent the real hierarchy of the network: organization, site, charging station, EVSE or point, connector, meter, payment terminal, communication device, and relevant upstream equipment. It should also preserve serial numbers, model, hardware revision, firmware, configuration, warranty, installation date, and service history.

Require bulk import, controlled edits, validation, and an audit trail. A large CPO cannot manage thousands of assets through one-off support tickets.

Test common lifecycle events:

• Commissioning a new site and its identifiers

• Replacing a charger without losing site history

• Replacing one power module, cable, modem, or terminal

• Moving a charger to another location

• Splitting or merging operator portfolios

• Retiring an asset while retaining financial and compliance records

• Changing the hardware or CSMS supplier

The system should prevent duplicate EVSE identifiers and preserve the relationship between physical labels, OCPP addressing, roaming identifiers, payment lanes, public data, and finance records.

Procure OCPP functions rather than a version label

The Open Charge Alliance OCPP overview describes OCPP as the protocol between a charging station and a charging management system. OCPP 1.6 remains widely used and includes smart-charging support. OCPP 2.0.1 adds improved transaction handling, device management, security, smart charging, ISO 15118 support, and display functions. OCPP 2.1, released in 2025, adds further energy, transaction, and ad hoc payment functions.

OCPP 1.6 and 2.0.1 are not compatible. A CPO planning a mixed estate needs an explicit version and migration policy.

Requirement area	Questions for the CSMS vendor
Connection	Which transports, security profiles, certificates, and reconnect behaviors are supported
Status	How are unavailable, reserved, occupied, faulted, and unknown states interpreted
Transactions	How are starts, stops, meter values, reboot recovery, and missing events handled
Remote operations	Which start, stop, reset, unlock, configuration, and diagnostic commands are supported
Smart charging	Which charging profiles, schedules, limits, priorities, and local fallbacks are implemented
Device management	Which variables, components, monitoring reports, and firmware functions are available
Custom extensions	Which charger behaviors depend on proprietary APIs or DataTransfer messages

Use the OCPP certification programme to verify conformance evidence for the exact CSMS product, version, and certificate scope. Certification reduces uncertainty but does not replace testing with the selected chargers, firmware, optional devices, and operating configuration.

Ask the vendor to demonstrate at least two charger manufacturers. A multi-vendor claim supported only by a compatibility list should not receive full evaluation credit.

Make remote operations actionable

A dashboard is useful only when operators can diagnose and resolve a meaningful share of incidents. The platform should combine current state, recent events, configuration, connectivity, transactions, power limits, and service history in one traceable view.

Define alert rules by impact rather than sending every charger event to staff. Examples include:

• Entire site unreachable

• One connector repeatedly failing to start

• Payment approved with no charging transaction

• Session active without meter progression

• Charger available in the CSMS but unavailable in public data

• Repeated resets, ground faults, overtemperature, or cable-lock errors

• Terminal or acquirer unavailable while chargers remain online

• Site demand approaching the approved limit

• Clock drift or missing meter records

Each alert needs severity, deduplication, owner, diagnostic evidence, automatic action if allowed, escalation time, and closure criteria. The CSMS should open or update a ticket through an API rather than relying on manual re-entry.

Require mass operations with safeguards. Firmware, configuration, certificate, tariff, and power-profile changes should support pilot groups, scheduling, progress tracking, failure isolation, rollback, and an immutable audit history.

Protect transaction and meter integrity

Charging transactions are operational and financial records. The CSMS should preserve the original charger events, timestamps, meter values, authorization reference, connector identity, stop reason, applied tariff version, and any later correction.

Define recovery for:

1. Charger starts locally while the CSMS is offline.

2. The CSMS sends a start command but loses the response.

3. The charger reboots during an active session.

4. The stop event arrives without a final meter value.

5. Duplicate messages arrive after reconnection.

6. The vehicle stops drawing power but remains connected.

7. A field technician ends or edits a session.

Use idempotent commands and stable references where the interfaces support them. Corrections should create an audit event instead of overwriting the original record silently.

The CSMS also needs clock monitoring. Incorrect timestamps can break tariffs, idle fees, roaming records, settlement periods, and incident timelines even when energy values remain accurate.

Separate payment orchestration from card processing

The management system may initiate or track payment steps, but the PSP and acquirer process bank-card authorization, capture, reversal, refund, and settlement. Keep sensitive card data within the approved payment environment and exchange non-sensitive tokens or references with the CSMS.

Require the platform to correlate:

• Site, charger, EVSE, connector, and terminal

• Tariff version and currency

• Payment authorization and any hold

• Charging transaction and meter record

• Final calculation and capture

• Receipt, refund, chargeback, and settlement item

Test failure states, not only successful taps. If authorization succeeds but the charger does not start, the system should determine whether energy was delivered and reverse or release the amount under the agreed rule. Retrying an uncertain capture must not create a duplicate charge.

The tariff engine should support the components and disclosure rules needed in each market. It should retain the price shown before the session, effective dates, taxes, discounts, roaming treatment, and manual changes. Finance needs a reconciliation export that explains differences among charging records, captures, refunds, PSP settlement, bank deposit, and accounting entries.

Add roaming through a separate interface

OCPP is not a roaming protocol. The CPO needs another interface for exchanging location, tariff, token, session, and charging data records with eMSPs or hubs.

The EVRoaming Foundation’s OCPI downloads page lists OCPI 2.3.0 with AFIR-related data and Direct Payment support. It also provides OCPI 2.2.1-d2, which covers core functions such as locations, tariffs, tokens, sessions, charging data records, remote tools, and smart charging.

Specify the exact OCPI version, modules, roles, push or pull behavior, credentials, pagination, currency and tax treatment, timeout handling, and retry rules. Confirm whether the CPO connects directly to eMSPs, through a hub, or both.

Test:

• New and updated locations and connectors

• Tariff publication and effective dates

• Token authorization and blocked-token propagation

• Remote start and stop

• Live session updates

• Final charging data records and corrections

• Partner outage and replay after recovery

• Reconciliation of partner records and invoices

Maintain one identifier register across OCPP, OCPI, public data, payment, and finance. A connector shown twice under different IDs can create both customer confusion and duplicate commercial records.

Include AFIR data and regulatory exports

For EU public networks, Article 20 of the current AFIR text requires specified static and dynamic data to be made available through an API, with API information provided to national access points. Required information includes asset, connector, power, status, availability, price, and other fields.

The CSMS may supply much of this data, but it rarely owns every field. Opening hours, accessible parking, operator contacts, coordinates, renewable-energy statements, and regulatory classifications may come from other systems. The platform should validate completeness, publish updates, monitor freshness, and report rejected records.

Ask the vendor to demonstrate the target country’s data path with a real schema and error response. A generic REST API does not prove compliance with national onboarding, profiles, identifiers, or operating procedures.

Control site power and charging priorities

The CSMS should respect an authoritative site limit and translate commercial or operational priorities into charger commands. It may coordinate with a local controller, building management system, meter, solar inverter, storage system, or utility signal.

Define:

• Static and dynamic site limits

• Per-charger and per-connector limits

• Minimum current and charger behavior below it

• Equal-share, first-come, departure-based, fleet, or paid-priority rules

• Schedule and tariff signals

• Recovery after charger or controller disconnection

• Local safe limit during cloud or meter failure

• Manual override authorization and expiry

• Evidence of requested and applied limits

The system should distinguish requested power, charger limit, vehicle request, and delivered power. Otherwise support teams may blame load management for a slow session caused by the vehicle or temperature.

Do not evaluate smart charging only in a live demonstration with two points. Test the expected site size, simultaneous events, reconnect storms, priority changes, and controller failure.

Require usable APIs and data portability

APIs should cover the workflows the CPO actually plans to automate. Request documentation and a sandbox before contract signature. Evaluate authentication, authorization, rate limits, pagination, filtering, webhooks, versioning, error messages, idempotency, audit records, and deprecation policy.

Data export should include:

• Sites, assets, identifiers, configurations, and firmware

• Users, credentials, groups, and authorization policies

• Tariffs and complete version history

• Sessions, meter values, stop reasons, and corrections

• Non-sensitive payment references and reconciliation status

• Roaming partners, records, and charging data records

• Alerts, tickets, maintenance, and availability calculations

• Power limits, charging profiles, and control events

• Administrative users, roles, and audit logs

Run a sample export and re-import exercise. Define format, frequency, completeness, transfer method, cost, and delivery time in the contract. The exit clause should cover credentials, certificates, DNS or endpoint changes, terminal and roaming migration, historical data, and transition support.

Evaluate security and service operations

The platform should support role-based access, least privilege, multifactor authentication, single sign-on where required, audit logs, secure secrets and certificates, encryption, vulnerability management, backups, disaster recovery, incident notification, and controlled vendor access.

Request evidence for secure development, penetration testing, dependency management, patching, data segregation, subcontractors, data location, recovery tests, and breach handling. Match the depth of evidence to network scale and criticality.

Service levels must define more than monthly availability. Include:

• Support coverage and severity definitions

• Initial response and restoration targets

• Planned maintenance notice and exclusions

• Data backup and recovery objectives

• Maximum data loss and synchronization delay

• Incident communication and root-cause reports

• API and roaming service measures

• Performance at expected charger and transaction volume

• Service credits and chronic-failure remedies

Verify how the vendor measures its SLA and whether a failure in a critical module can be excluded while the portal remains technically online.

Score vendors against CPO outcomes

A weighted scorecard keeps a polished demonstration from outweighing operational risk. An example allocation is:

Evaluation category	Suggested weight	Evidence to score
Core charging and transaction operations	20	Scripted use cases, event records, recovery tests
OCPP and multi-vendor interoperability	15	Certificates, supported functions, live charger tests
Tariffs, payment, roaming, and finance	15	End-to-end journeys and reconciliation output
Monitoring, maintenance, and service levels	15	Alert workflow, SLA, incident history, service demo
Smart charging and energy integration	10	Site-scale test, controller interfaces, fallback proof
Security, privacy, and access control	10	Architecture and current assessment evidence
APIs, data, regulatory reporting, and portability	10	Sandbox, exports, AFIR path, migration exercise
Implementation, training, roadmap, and exit	5	Named plan, resources, references, contractual rights

Set minimum pass conditions in addition to total score. A platform should not win with strong reporting if it fails a mandatory transaction-recovery, security, or data-export test.

Run a scenario based proof of concept

Use production-like hardware, firmware, communications, identifiers, and payment or roaming sandboxes. Include at least these scenarios:

1. Commission a multi-output charger and publish it correctly.

2. Authorize and complete local, RFID, card, and roaming sessions as required.

3. Recover active and completed sessions after charger and CSMS outages.

4. Apply a scheduled tariff change and reconcile the final charge.

5. Detect a repeated start failure and create a service ticket with evidence.

6. Enforce a site limit while priorities and vehicle demand change.

7. Roll out and roll back a configuration or firmware change.

8. Export a complete site and its operating history.

9. Remove vendor access and rotate relevant credentials.

10. Demonstrate regulatory data publication for the target market.

Record configuration, timestamps, protocol messages, screens, exports, financial references, expected result, and actual result. Make critical proof-of-concept cases contractual acceptance tests.

Review Luxman connected charging options

Luxman’s public charging solution describes smart energy management and white-label options, with selected DC configurations listing POS payment, ISO 15118, Modbus TCP, and optional Ethernet, Wi-Fi, or 4G.

Use this for integration discovery, not as a complete CSMS specification. Confirm the exact charger model, firmware, OCPP functions, metering, commands, profiles, communications, and tested backend. Assign management, payment, roaming, AFIR-data, energy-control, hosting, and SLA responsibilities separately.

Frequently asked questions

What is an EV charging management system for CPO operations?

It connects to chargers and manages status, authorization, transactions, meter data, tariffs, remote operations, reporting, and integrations. Other modules may be native or separate.

Is a CSMS the same as a charger app?

No. A driver app is a customer interface; the CSMS manages infrastructure and operating records across sites, chargers, users, and partners.

Which OCPP version should a CPO choose?

Choose functions supported by both charger and CSMS. OCPP 1.6 remains common; verify version compatibility, certification scope, security, migration, and project tests.

Does the management system process credit cards?

It may orchestrate sessions, but a PSP and acquirer normally process and settle bank-card transactions. Document the payment-data boundary.

How can a CPO avoid CSMS lock in?

Require open functions, usable APIs, stable identifiers, complete exports, credential transition, migration assistance, and tested exit procedures.

What should be tested before CSMS rollout?

Test authorization, recovery, tariffs, payments, roaming, power control, alarms, updates, security, regulatory data, exports, backup, and exit on actual chargers.

EV charging management system for CPO conclusion

An EV charging management system for CPO use should preserve asset identity, recover transactions, control tariffs and power, expose usable data, and support the charger lifecycle through tested operating scenarios.

For integration review, send Luxman Energy the charger, OCPP, backend, payment, roaming, metering, tariff, power-control, communications, security, export, and test requirements. Luxman can confirm interfaces and dependencies.