EV Charging Platform Development Guide for the UAE

An EV charging platform for the UAE must handle OCPP 1.6J, OCPP 2.0.1, or OCPP 2.1 communication, emirate-specific utility requirements, dynamic charging tariffs, real-time station availability, payment and billing, and OCPI-based roaming. The software also needs to connect chargers from different manufacturers to one CSMS, support reservations and fleet charging, and preserve transaction records for billing and reconciliation. Dubai requires independent public Charge Point Operators to obtain the applicable DEWA licence, while other emirates follow their own utility and regulatory frameworks.

Why EV Charging Platforms Need More Than a Mobile App

An EV charging business is not simply a location directory with a payment screen. The software sits between physical charging equipment, vehicles, electricity infrastructure, customers, fleet operators, payment systems, utilities, and potentially other charging networks.

That makes the Charge Point Management System (CPMS), also called a Charging Station Management System (CSMS), the operational core of the platform.

A customer application can show charger locations and start a session, but the backend must communicate with chargers, process transaction events, determine whether a connector is available, calculate the session cost, reconcile the payment, and maintain an auditable charging record.

The UAE adds another layer because charging infrastructure is governed through emirate-specific utility and transport frameworks. Dubai's current framework establishes requirements for EV charging infrastructure and independent Charge Point Operator (CPO) licensing. The software architecture should therefore support the operator's applicable regulatory and commercial model rather than assume that one generic UAE workflow applies everywhere.

The platform architecture needs to be designed around physical charging operations first and the customer application second.

Pixbit has direct EV charging domain experience through a charging-station finder and management application developed in collaboration with a state electricity board and serving more than 50,000 active users. This experience is relevant to charging discovery, station management, and user-scale operations, but it is not being presented as UAE-specific delivery.

OCPP Is the Communication Foundation

The Open Charge Point Protocol (OCPP) provides the communication layer between charging stations and the charging management system. Its architectural value is that a CPO can manage compatible charging hardware without building the entire backend around one manufacturer's proprietary interface.

The Open Charge Alliance currently lists OCPP 1.6, OCPP 2.0.1, and OCPP 2.1. OCPP 1.6 remains widely used, while OCPP 2.0.1 and OCPP 2.1 provide newer capabilities for charging management, security, smart charging, and related use cases.

For a new UAE platform, this distinction matters because charger procurement can span multiple generations. A CPO may have existing OCPP 1.6J chargers while new deployments support OCPP 2.0.1 or 2.1.

OCPP 1.6 and OCPP 2.0.1 are not backward compatible. A platform that expects to manage both should therefore implement separate protocol handling behind a common internal charging model instead of assuming that messages and capabilities are identical across versions.

What BootNotification and Heartbeat Actually Do

When a charger connects to a CSMS, BootNotification provides information about the charging station and establishes the initial communication relationship. The backend can use the event to register or validate the charger and return configuration information, including the heartbeat interval.

Heartbeat allows the charging station to indicate that it remains connected. This matters because a charger appearing in a database does not necessarily mean that its communication channel is currently healthy.

A production platform should distinguish between operational state and communication state. A charger can be physically powered while its network connection to the CSMS is unavailable. The backend should therefore maintain connectivity timestamps and state rather than simply displaying a static "online" flag.

Transaction events are equally important. In OCPP 1.6, messages such as StartTransaction, MeterValues, and StopTransaction provide the basis for tracking a charging session. OCPP 2.0.1 changes the transaction model and introduces a more detailed device model for configuration and monitoring.

This data feeds the session record, billing engine, customer history, energy reporting, and operational dashboards.

Why Hardware-Agnostic Architecture Matters

A CPO should be able to replace or add charger brands without rewriting the customer application, billing engine, fleet module, and reporting system.

That requires the backend to treat the charger protocol as an integration boundary.

The platform can normalize charger data into internal objects such as charging station, EVSE, connector, session, meter value, authorization, reservation, and fault. The customer-facing systems then consume those normalized objects instead of communicating directly with individual charger manufacturers.

This approach becomes particularly important when a network grows through multiple procurement contracts. A CPO can introduce a new charger model while keeping the same mobile application, account system, payment gateway, tariff engine, and reporting infrastructure.

OCPP 2.0.1 adds capabilities including device management, improved transaction handling, security, smart charging, and ISO 15118-related functionality. OCPP 2.1 extends the protocol with additional capabilities including ISO 15118-20, bidirectional charging, Distributed Energy Resource control, expanded smart charging, battery swapping, local cost calculation, and additional payment options.

The platform should not assume that every charger supports every feature. Capability discovery and version-aware behaviour are essential.

UAE Utility and Regulatory Requirements

The approval and operating model depends on where the charging infrastructure is installed.

DEWA Requirements in Dubai

In Dubai, DEWA's current EV Charging Infrastructure Regulation establishes the framework for EV charging infrastructure and independent CPO licensing.

DEWA states that independent CPOs operating public EV charging infrastructure in Dubai must obtain a CPO licence. DEWA also distinguishes between CPOs providing free charging services and CPOs collecting payments from end users.

This has an important software implication. The platform should be able to represent the operator's commercial model, charging locations, assets, tariffs, sessions, payments, and operational records separately rather than treating every charger as an identical public charging point.

The installation and approval side should also remain separate from the customer-facing application. Electrical design, site requirements, charger specifications, utility connection information, and authority documentation belong in an infrastructure and compliance layer.

ADDC and Abu Dhabi Charging Infrastructure

Abu Dhabi follows a different regulatory and utility structure.

ADDC's current information states that EV chargers must be registered with ADDC or AADC when applicable within the Emirate of Abu Dhabi. ADDC also provides an EV charger registration process that captures information associated with the utility account, installed chargers, and metering.

The software should therefore support utility-specific asset records rather than assume that the Dubai CPO workflow can simply be copied into Abu Dhabi.

Abu Dhabi's EV charging governance also includes requirements around monitoring consumption and metering. For a platform serving commercial properties, fleets, or public charging networks, this makes meter and energy-consumption data important inputs into the overall charging architecture.

FEWA and Etihad Water and Electricity

The former Federal Electricity & Water Authority (FEWA) is now Etihad Water and Electricity (EtihadWE).

For charging projects within EtihadWE's service areas, the applicable utility requirements need to be considered separately from Dubai and Abu Dhabi frameworks.

The important architectural principle is not to hard-code a single "UAE approval" process.

Instead, each charging site should have structured information for its emirate, utility, electrical connection, charger specifications, meter details, installation records, approval status, and supporting documents.

That allows the same software platform to support multiple operating regions without pretending that every authority uses identical processes.

Where RTA Fits

RTA can become relevant to Dubai charging projects where infrastructure intersects with transport facilities, roads, right-of-way, mobility infrastructure, or other RTA-controlled assets.

The exact authority involvement depends on the physical location and project scope. A software platform should therefore support document and approval tracking where required, while the implementation team verifies the actual project-specific authority sequence rather than claiming that one RTA process applies to every EV charger installation.

Dynamic Pricing and EV Charging Billing

Charging tariffs should be treated as a dedicated pricing service rather than a fixed value stored against a charger.

A simple public charging model may charge per kilowatt-hour. Another operator may charge per minute, apply a connection fee, introduce an idle or parking charge, or combine multiple pricing components.

Time-of-use pricing adds another variable. The pricing engine needs to determine which tariff applies based on the charging start time, charging period, location, customer type, and charger category where applicable.

The session record should preserve the tariff version used for the transaction. If the tariff changes later, the operator should still be able to reproduce how an earlier charging session was calculated.

A practical pricing architecture separates the tariff definition from the charging session itself.

The tariff service can receive information such as the site, EVSE, customer category, session start time, energy consumed, duration, and applicable pricing rules. It then returns the charge calculation to the billing service.

This separation is important when an operator introduces different pricing structures across locations or customer groups.

Payment Gateway Integration

For pay-per-use charging, the payment flow should support authorization before charging where required, session initiation after successful authorization, final amount calculation after the session, and reconciliation when the charger or network connection fails.

The system also needs to handle interrupted sessions.

A customer may lose connectivity, a charger may restart, or a payment provider may return a delayed response. The backend should not create duplicate charges simply because the same transaction event is received more than once.

Idempotent transaction processing is therefore an important part of charging billing architecture.

The payment record should also remain linked to the charging session, tariff version, meter readings, customer account, and final amount. This gives operators a traceable chain from physical energy consumption to the financial transaction.

Real-Time Station Availability, Reservations, and Queues

A charging station map is only useful when its availability reflects the physical state of the network.

The platform should distinguish between a charger being available, occupied, reserved, unavailable, faulted, offline, or undergoing maintenance.

These states can originate from charger messages, operator actions, scheduled maintenance, reservations, or communication failures.

The backend should maintain the state of the station, EVSE, and connector separately where the hardware model requires it. One charging station can contain multiple EVSEs, and an EVSE can expose multiple connectors depending on the equipment architecture.

This distinction becomes important when the customer application needs to show exactly which connector can be used.

Reservation Architecture

Reservations require their own state machine.

When a driver reserves a connector, the system should create a temporary hold with a defined start window and expiration rule. If the driver does not arrive, the reservation can expire and return the connector to the available pool.

The reservation service should also handle conflicts between operational status and booking status.

A connector that develops a fault after being reserved should not remain presented as a guaranteed booking. The system needs to notify the customer, release or reschedule the reservation according to the business rules, and update the station state.

Queue Management

Queue management becomes relevant at high-demand charging sites.

Instead of allowing multiple drivers to repeatedly request the same connector, the platform can maintain a queue for a charging location or EVSE.

The queue service can account for arrival time, reservation priority, estimated completion time, cancellations, and charger faults.

This logic belongs in the backend rather than the mobile application because the same queue state may need to be consumed by the operator dashboard, customer app, website, and potentially roaming partners.

OCPI Roaming for Multi-Operator Networks

A UAE charging network does not have to remain isolated inside its own mobile application.

The Open Charge Point Interface (OCPI) is designed for communication between charge point operators and e-mobility service providers. It supports the exchange of information such as locations, tariffs, tokens, sessions, and charge detail records.

The current official OCPI release is 2.3.0.

For a UAE CPO, implementing roaming means more than publishing a charger location API.

The platform needs to establish credentials between roaming partners, synchronize location and EVSE information, exchange tariff information, authorize tokens, exchange session updates, and reconcile charge detail records.

A driver using a partner eMSP application should be able to discover an eligible charger, authenticate, start a session, receive session information, and have the resulting charging transaction represented correctly between participating networks.

The CPO therefore needs an OCPI gateway that sits between the internal CSMS and external roaming partners.

This gateway should translate internal charging objects into the relevant OCPI structures while keeping the core charging platform independent of a specific roaming partner.

OCPI Version and Partner Compatibility

The existence of an OCPI standard does not mean that every roaming partner implements exactly the same version, modules, or optional capabilities.

The platform should therefore maintain partner-specific configuration and compatibility rules.

For example, one partner may support location, tariff, token, session, and CDR exchange, while another may use additional booking functionality.

A well-designed OCPI layer prevents these differences from spreading into the core charging system.

The CSMS continues to operate around its own internal charging model, while the roaming gateway handles the external representation required by each partner.

Fleet Charging and Public Charging Need Different Workflows

Consumer public charging is transaction-driven.

A driver finds a charger, authenticates, starts a session, pays, and leaves.

Fleet charging is different.

A logistics operator may manage vehicles, drivers, charging sessions, depots, and charging windows. The fleet manager may need cost allocation by vehicle, department, route, depot, or driver.

Access control can also be different. A fleet charger may be restricted to approved vehicles or RFID credentials rather than being open to every customer.

Fleet charging also requires scheduling.

A depot with limited electrical capacity cannot necessarily charge every vehicle at maximum power simultaneously. The platform may need smart charging rules that allocate available capacity according to departure time, battery requirements, vehicle priority, and site limits.

OCPP's smart charging capabilities provide protocol-level mechanisms that can support these scenarios, while the business rules belong in the CSMS or energy management layer.

Reporting also differs.

A public network may focus on revenue, utilization, sessions, energy delivered, and charger availability.

A fleet operator may care more about energy consumed per vehicle, charging cost per kilometre, depot utilization, scheduled departure readiness, driver activity, and electricity demand.

A platform serving both markets should therefore share the charging core but separate the customer, fleet, pricing, reporting, and access-control workflows.

White-Label CPMS vs. a Custom EV Charging Platform

Packaged charge point management systems can be the right choice when the operating model fits the product's existing assumptions.

A packaged CPMS can reduce the amount of infrastructure that a CPO has to develop itself. This can be particularly useful when the operator has a standard deployment, uses compatible charger hardware, follows a conventional billing model, and does not need extensive integration with property, fleet, utility, or enterprise systems.

The trade-off appears when the business model becomes more specific.

A CPO operating multiple charger brands may need different OCPP versions, vendor-specific behaviour, diagnostics, and charger capabilities.

A fleet operator may need charging schedules, vehicle-level reporting, depot controls, and cost allocation that differ from public charging.

A property group may need the charging platform connected to parking, access control, building management, tenant billing, visitor management, or an existing ERP.

A packaged CPMS can still be appropriate if those integrations and workflows are supported by the selected product. The question is whether the platform's existing architecture matches the business rather than whether packaged software is inherently good or bad.

Custom development becomes more relevant when the charging network needs several hardware vendors, custom tariff logic, fleet-specific workflows, OCPI roaming, or integration with existing property, utility, mobility, or enterprise systems.

A custom platform also gives the operator control over its internal data model and integration layer. That can matter when charging is one part of a larger mobility or energy product.

The practical decision is therefore to compare the cost and complexity of adapting a packaged CPMS against the cost and responsibility of owning a custom platform.

The evaluation should include charger compatibility, OCPP versions, OCPI requirements, tariffs, payment processing, fleet management, reporting, integrations, data ownership, and future expansion.

How to Architect an EV Charging Platform for the UAE

A practical architecture separates the charger communication layer from the business application layer.

The OCPP gateway handles connections with charging stations and normalizes protocol messages.

The CSMS maintains charger, EVSE, connector, session, meter, fault, authorization, and transaction state.

Above this sits the tariff and billing service, which calculates charges and produces transaction records.

The identity and access layer manages customer accounts, RFID credentials, vehicle information, fleet permissions, and authorization.

The reservation and availability services manage station state, bookings, queues, and real-time availability.

The OCPI gateway handles roaming connections with external CPOs and eMSPs.

The customer applications can then consume these services through APIs without directly depending on charger manufacturers.

For a UAE deployment, the platform should also maintain site and compliance records.

Each charging location can store its emirate, utility, electrical connection information, charger specifications, approval status, installation records, and relevant authority documentation.

The architecture can then expose the required information through separate interfaces for operators, customers, fleet managers, administrators, roaming partners, and external enterprise systems.

This separation also makes testing easier.

OCPP protocol testing can be handled independently from tariff testing. Payment reconciliation can be tested independently from mobile application behaviour. OCPI partner testing can be performed without changing the core session engine.

That matters because EV charging software has several failure points that do not exist in a conventional e-commerce or booking application.

A charger can disconnect.

A meter reading can arrive late.

A payment authorization can time out.

A roaming partner can send an unexpected state update.

A reservation can overlap with a charger fault.

The architecture needs to treat these as normal operational conditions rather than exceptional cases.

EV Charging Platform Development Summary

Requirement	What It Means	Software Implication
OCPP 1.6J / 2.0.1 / 2.1	Chargers communicate with the CSMS through defined protocol versions.	Build a version-aware OCPP gateway and normalize charger data internally.
Utility compliance	Charging infrastructure must follow the applicable emirate's utility and regulatory framework.	Store site, utility, meter, approval, and documentation data instead of using one generic UAE workflow.
Dynamic tariffs	Charging prices can depend on energy, time, duration, or configured tariff rules.	Use a dedicated tariff engine with versioned pricing and auditable calculations.
Real-time availability	Station state must reflect actual charger and network conditions.	Process OCPP events and publish state changes across apps, dashboards, and APIs.
Reservations and queues	Drivers may reserve connectors or wait for high-demand chargers.	Implement reservation expiry, queue state, priority, and conflict handling.
OCPI roaming	Drivers can access participating networks through partner platforms.	Build an OCPI gateway for locations, tokens, tariffs, sessions, and CDR exchange.
Fleet charging	Commercial operators need vehicle, driver, depot, scheduling, and cost controls.	Add fleet-specific access, reporting, smart charging, and cost allocation.
Payment and billing	Public charging requires reliable authorization, settlement, refunds, and reconciliation.	Integrate payment processing with session state and idempotent transaction handling.
Hardware independence	CPOs may operate chargers from multiple manufacturers.	Keep charger protocols behind an integration layer instead of coupling the app to OEM APIs.
Site and approval records	UAE projects can involve different utility and authority requirements.	Maintain emirate-specific site, utility, documentation, and approval data.

Frequently Asked Questions

What protocol should an EV charging platform in the UAE support?

An EV charging platform should assess support for OCPP 1.6J, OCPP 2.0.1, and OCPP 2.1 based on the existing and planned charger fleet. OCPP 1.6 remains widely used, while OCPP 2.0.1 and 2.1 provide newer capabilities. OCPP 1.6 and OCPP 2.0.1 are not backward compatible, so the CSMS architecture should account for protocol differences.

Does an EV charging platform need DEWA approval in Dubai?

The software platform itself is not the same thing as charging infrastructure approval. In Dubai, DEWA's current framework requires independent CPOs operating public EV charging infrastructure to obtain the applicable CPO licence and comply with the EV Charging Infrastructure Regulation. Project-specific site, electrical, and authority requirements also need to be addressed.

What is the difference between OCPP and OCPI?

OCPP primarily handles communication between charging stations and the charging management system. OCPI handles communication between charging operators and e-mobility service providers for use cases such as location exchange, authorization, tariffs, sessions, and charge detail records. They solve different integration problems and can be used together.

Can an EV charging platform support both public charging and fleet charging?

Yes. The same charging management core can support both models, but the business workflows differ. Public charging generally focuses on customer authentication, payment, reservations, and session billing, while fleet charging adds vehicle groups, driver access, depot scheduling, cost allocation, smart charging, and fleet-specific reporting.

How much does it cost to build an EV charging platform in the UAE?

The development cost depends on the number of charger brands and OCPP versions, mobile applications, payment requirements, tariff complexity, OCPI roaming, fleet functionality, utility-related workflows, integrations, and reporting requirements. A discovery assessment is normally needed before defining the exact scope and cost.

Conclusion

An EV charging platform for the UAE needs to be designed as infrastructure software rather than as a simple charging app.

OCPP provides the charger communication layer, while OCPI can connect the network to roaming partners. Above these protocols, the platform needs tariff calculation, billing, real-time availability, reservations, fleet management, payment processing, and operational reporting.

The regulatory layer also needs to reflect the emirate in which the infrastructure operates.

Dubai has a current DEWA CPO licensing framework. Abu Dhabi has EV charger registration requirements through ADDC or AADC where applicable. The Northern Emirates fall under the applicable EtihadWE framework. RTA may also become relevant to specific Dubai projects involving transport infrastructure or right-of-way requirements.

The exact approval and installation requirements depend on the project, site, charger type, electrical connection, ownership model, and applicable authority.

A packaged CPMS can be suitable when its charger compatibility, pricing, billing, reporting, and integration model matches the operator's requirements.

A custom platform becomes more relevant when the business needs multiple hardware vendors, specialised tariff logic, fleet workflows, OCPI roaming, or integration with existing property, utility, ERP, or mobility systems.

Pixbit develops EV charging platforms using Laravel, React, Next.js, and Flutter, with the architecture defined around the operator's charger fleet, protocols, commercial model, integrations, and target market.

Development cost and timeline depend on scope. Pixbit scopes exact cost and timeline in a single discovery session.