Unified Bharat e-Charge: A Developer Guide

India is building Unified Bharat e-Charge (UBC) as a government-backed interoperability platform for public EV charging, with an ambition comparable to UPI's impact on digital payments. Led by BHEL under the Ministry of Heavy Industries and built on the open Beckn Protocol, UBC aims to let EV users discover, reserve, and pay for charging sessions across multiple Charge Point Operators (CPOs) through interoperable applications rather than operator-specific ecosystems. For CPOs, this changes the software architecture itself—future Charge Point Management Systems (CPMS) will need to expose charger availability, reservations, and payment transactions through standardized Beckn interfaces instead of serving only their own mobile applications. While the initiative remains under development and technical specifications continue to evolve, its direction is already influencing how new CPMS platforms should be designed.

---

What Unified Bharat e-Charge Actually Is — And What It Isn't

Much of the early discussion around Unified Bharat e-Charge suggests that it will become a single national charging application replacing existing CPO apps.

That interpretation is inaccurate.

UBC is being designed as an interoperability layer rather than a replacement ecosystem.

The underlying idea closely mirrors the architecture already demonstrated by Beckn-powered networks such as ONDC.

Instead of forcing every operator into one application, UBC allows independent charging networks to remain operational while becoming discoverable through a common digital layer.

Drivers may continue using a CPO's own application if they choose.

Third-party mobility platforms may also participate.

Fleet management systems could integrate charging directly into their own workflows.

All of these applications communicate through the same interoperability framework instead of requiring separate commercial integrations with every charging network.

The result is greater market reach without removing operator independence.

For Charge Point Operators, this represents an important architectural shift.

Historically, the customer journey has been tightly coupled to the operator's own mobile application.

Discovery, authentication, payment, charger availability, and charging history all existed inside one closed ecosystem.

Unified Bharat e-Charge separates these concerns.

The charging infrastructure remains under the operator's control, while customer acquisition and transaction initiation can originate from multiple external applications.

This makes interoperability a platform capability rather than a business partnership.

The government's objective is therefore not to standardise user interfaces.

It is to standardise how charging networks communicate with one another through open digital protocols.

That distinction has significant implications for backend software.

Future-ready CPMS platforms should assume that charging requests may originate from multiple Beckn-compatible applications instead of only the operator's proprietary mobile app.

This approach also creates healthier competition.

CPOs continue differentiating themselves through charger reliability, pricing, network coverage, customer service, and operational efficiency rather than relying solely on application lock-in.

The interoperability layer simply reduces friction for EV drivers while allowing the underlying charging ecosystem to remain decentralised.

The Beckn Protocol, Briefly, for Developers

Unified Bharat e-Charge is being built on the Beckn Protocol, an open protocol designed to enable decentralised digital commerce rather than creating another centralised marketplace.

Unlike proprietary APIs owned by a single platform provider, Beckn defines a common language that allows independent buyer applications and service providers to discover, negotiate, and complete transactions without requiring bespoke integrations between every participant.

The protocol has already been adopted in initiatives such as ONDC and various mobility projects, making it a logical foundation for a nationwide EV charging network where hundreds of independent Charge Point Operators need to interact with multiple consumer applications.

For developers building CPMS platforms, Beckn introduces a new interoperability layer that sits above the charging infrastructure itself.

The charger still communicates with the backend through OCPP.

The customer-facing application, however, communicates with the backend through Beckn.

These are complementary technologies rather than competing standards.

Understanding the Transaction Flow

A Beckn transaction follows a predictable lifecycle.

When an EV driver searches for nearby charging stations, the buyer application issues a /search request across the network.

Instead of querying one operator's database, the request is routed to participating providers whose systems return available charging locations, connector types, pricing information, operational status, and other discoverable metadata.

Once the user selects a charging station, the application proceeds with a /select transaction.

At this stage, the selected charging option, tariff, availability, and reservation details are confirmed between the buyer application and the CPO's backend.

If the chosen charger supports advance reservation, this is where availability validation becomes particularly important.

The final booking occurs through a /confirm transaction.

Only after successful confirmation should the charging session be reserved within the operator's CPMS.

From that point onwards, the charging workflow returns to the operator's existing infrastructure, where OCPP manages charger communication, session initiation, metering, charging status, and session completion.

The Beckn layer effectively handles the commercial transaction, while OCPP continues managing the physical charging operation.

Designing for External Consumers

Historically, most Indian CPMS platforms were built around a single consumer—the operator's own mobile application.

Every API endpoint assumed that requests originated from software developed by the same organisation.

Unified Bharat e-Charge changes that assumption completely.

Future CPMS platforms should treat every Beckn-compatible application as a legitimate transaction source.

Whether the booking originates from the operator's mobile app, a vehicle manufacturer's navigation system, a fleet management platform, or another mobility application becomes largely irrelevant.

The backend should process all requests consistently while enforcing authentication, authorisation, pricing policies, reservation rules, and operational constraints.

This requires API-first thinking.

Instead of tightly coupling business logic to a specific frontend experience, developers should expose well-defined service interfaces capable of supporting multiple client applications simultaneously.

Interoperability Without Replacing Existing Infrastructure

One of the strengths of Beckn is that it avoids forcing operators to replace their existing technology stack.

Most CPOs have already invested heavily in charger management software, payment systems, customer applications, and operational dashboards.

Unified Bharat e-Charge is expected to integrate with these systems rather than replace them.

The Beckn interface becomes another entry point into the existing platform.

Internally, the CPMS can continue using established business logic, OCPP integrations, billing engines, CRM systems, and monitoring infrastructure.

Externally, however, it exposes standardised discovery and transaction capabilities that allow any compliant application to interact with the charging network.

For developers, this separation of concerns is significant.

Rather than rebuilding the charging platform itself, most implementation work will focus on creating a Beckn-compatible interoperability layer that maps standard protocol transactions into existing CPMS workflows while maintaining security, performance, and operational consistency.

What This Means for CPMS Architecture

Unified Bharat e-Charge introduces a second interoperability layer for Charge Point Operators.

Until now, most CPMS platforms have focused primarily on one responsibility—communicating with charging hardware through OCPP while exposing operator-specific APIs to their own mobile applications.

As UBC evolves, that architecture begins to change.

The CPMS will continue managing chargers through OCPP, but it will also need to expose standardized Beckn-compatible interfaces that allow external applications to discover chargers, initiate reservations, and complete transactions without relying on proprietary integrations.

Rather than replacing existing infrastructure, Beckn extends it.

This is why CPOs should think of UBC as an interoperability layer sitting above the operational charging platform.

The physical charger still communicates with the backend exactly as it does today.

The difference lies in how customers reach that backend.

Instead of every charging request originating from the operator's own application, requests may arrive from fleet platforms, navigation systems, EV manufacturers, mobility applications, or other Beckn-enabled consumer experiences.

The CPMS becomes responsible for responding consistently regardless of where the transaction originated.

OCPP and Beckn Solve Different Problems

Many discussions incorrectly position Beckn as an alternative to OCPP.

The two protocols address entirely different parts of the charging ecosystem.

OCPP governs communication between the charging station and the Charge Point Management System.

It handles boot notifications, charger availability, remote start and stop commands, meter values, firmware updates, diagnostics, and operational health.

Beckn, on the other hand, governs commercial interoperability.

It allows external applications to discover charging stations, retrieve pricing, reserve slots, and initiate charging transactions through standardized APIs.

One protocol manages the charger.

The other manages the marketplace.

Future-ready platforms therefore need both.

If OCPP ensures operational interoperability, Beckn enables commercial interoperability.

Neither replaces the other.

The CPMS Becomes an API Platform

This architectural shift means a modern CPMS should no longer be viewed as an application with an accompanying mobile app.

Instead, it becomes an API platform supporting multiple client ecosystems simultaneously.

Internally, it continues managing charging infrastructure, operator dashboards, billing engines, user accounts, and monitoring systems.

Externally, it publishes standardized services that expose real-time charger availability, tariff information, reservation capabilities, payment status, and session lifecycle events.

Every external application should receive consistent information regardless of whether it belongs to the operator, an automotive OEM, a fleet operator, or another Beckn participant.

This API-first approach also simplifies future expansion.

As interoperability initiatives mature, additional transaction types can be supported without fundamentally redesigning the charging platform itself.

Real-Time Data Becomes Critical

One consequence of UBC is that charger availability can no longer be treated as information refreshed every few minutes.

External applications will depend on accurate, near real-time operational data.

If a charger appears available through the Beckn network but is already occupied when the driver arrives, the interoperability layer quickly loses credibility.

The CPMS therefore needs reliable synchronization between charger telemetry received through OCPP and the information exposed through Beckn APIs.

Availability, operational status, connector faults, maintenance windows, pricing updates, and reservation state should all remain synchronized automatically.

Maintaining this consistency requires event-driven architecture rather than periodic database polling.

State changes occurring at the charger should propagate through the platform quickly enough for every connected application to reflect the same operational reality.

As discussed in our guide on EV Charging Station Management Software India, this reinforces the role of the CPMS as the operational foundation of every charging network.

Unified Bharat e-Charge does not replace that foundation—it extends it, requiring CPOs to think beyond charger management and design their platforms as interoperable digital infrastructure capable of serving an entire ecosystem rather than a single mobile application.

Slot Booking and Reservation — A New Capability Requirement

One of the most significant capabilities expected under Unified Bharat e-Charge is standardized charger reservation.

Today's public charging experience across much of India is still largely walk-up based.

Drivers locate an available charger, navigate to the site, and begin charging if the connector is free.

If another vehicle occupies the charger, the user either waits or searches for another location.

As EV adoption accelerates and public charging infrastructure becomes busier, this model becomes increasingly inefficient.

The vision behind UBC changes that experience by allowing drivers to reserve charging slots before they arrive.

Whether the reservation window is thirty minutes, one hour, or another configurable duration, the underlying software challenge remains the same.

The Charge Point Management System must now manage future capacity instead of only current availability.

Availability Is No Longer Binary

Traditional CPMS implementations typically expose a simple operational state.

A charger is available, occupied, faulted, or offline.

Reservation introduces another dimension.

A charger may appear physically available while already being reserved for an arriving driver.

Conversely, a charger may currently be occupied but become available within the driver's expected arrival window.

The platform therefore needs to calculate availability based on both operational telemetry and future reservations.

This requires a scheduling engine rather than a simple status indicator.

Every booking affects the availability presented to other users across the Beckn network.

Without accurate reservation management, drivers could easily receive conflicting information from different applications.

Reservation Management Requires New Business Logic

Supporting reservations is considerably more complex than creating calendar entries.

The software needs to enforce configurable reservation policies while maintaining fairness across the charging network.

Operators may choose different reservation windows depending on charger utilisation, location, fleet priorities, or commercial strategy.

The platform should therefore support configurable booking durations, automatic reservation expiry, cancellation handling, grace periods for late arrivals, and automatic release of unused reservations.

These policies should remain configurable without requiring application-level changes.

The charging workflow must also connect reservations directly to physical charger operations.

When a reserved vehicle arrives, authentication should immediately associate the charging session with the existing reservation instead of creating an entirely new transaction.

Likewise, if a reservation expires without the driver arriving, the charger should automatically return to the available pool so other users can access it.

Reservation State Must Stay Synchronized Across the Network

Unified Bharat e-Charge introduces another important architectural consideration.

Reservations may originate from applications that the operator neither owns nor controls.

A booking created through one Beckn-enabled application should become visible immediately across every participating platform.

If synchronization lags even by a few minutes, two separate users could successfully reserve the same charging slot through different applications.

Avoiding these conflicts requires event-driven synchronization rather than periodic data refreshes.

Every reservation confirmation, modification, cancellation, expiry, and charging session initiation should generate events that update availability across the interoperability layer almost immediately.

This consistency becomes particularly important as larger charging networks begin supporting thousands of simultaneous bookings across multiple cities.

Preparing for Reservation-Centric Networks

Although large-scale reservation workflows are still emerging within India's public charging ecosystem, their introduction represents one of the biggest architectural changes for CPMS platforms.

Instead of reacting only to charger status reported through OCPP, future systems will also need to predict future utilisation based on scheduled reservations.

This effectively transforms the CPMS from an operational monitoring platform into a capacity management platform.

For developers, the takeaway is straightforward.

Reservation should not be implemented as an isolated feature added to the mobile application.

It should become a core capability of the backend architecture itself, influencing availability calculations, pricing, authentication, session management, and Beckn interoperability from the moment the platform is designed.

What CPOs Should Build for Now, and What to Wait On

Unified Bharat e-Charge is one of the most important developments in India's EV charging ecosystem, but it is also still an evolving initiative.

The overall direction is becoming increasingly clear, while implementation details, certification processes, and technical specifications continue to mature.

That distinction matters.

CPOs should absolutely prepare their software architecture for interoperability, but they should avoid implementing assumptions that may become obsolete as the official framework develops.

The most valuable investment today is architectural flexibility.

Prioritise API-First Architecture

Many existing CPMS platforms were originally built around a single mobile application.

Business logic, user management, charger discovery, payments, and reservations often exist as tightly coupled application features rather than reusable platform services.

Future-ready systems should invert that model.

Core charging capabilities should exist as independent services with well-documented APIs.

Whether requests originate from the operator's own application, a fleet platform, an OEM, or a future Beckn-compatible application should become largely irrelevant.

This approach not only prepares the platform for Unified Bharat e-Charge but also simplifies integration with enterprise customers, roaming partners, and future digital ecosystems.

Separate Business Logic from Protocols

One common architectural mistake is embedding protocol-specific behaviour directly into business logic.

Today the platform may expose REST APIs for its own application.

Tomorrow it may need Beckn endpoints.

Future interoperability initiatives could introduce additional interface standards.

None of these changes should require rewriting the charger management platform itself.

Instead, protocol adapters should translate external requests into a consistent internal service layer.

The charger management engine, pricing engine, reservation engine, billing platform, and operational workflows remain unchanged regardless of how transactions enter the system.

This separation significantly reduces long-term maintenance while allowing interoperability capabilities to evolve independently.

Build for Real-Time Data Quality

Interoperability only works when every participant trusts the information being exchanged.

Real-time charger availability, operational status, connector health, reservation state, pricing, and payment confirmation should remain accurate across every external interface.

That makes event-driven architecture increasingly important.

Rather than relying on scheduled synchronisation jobs, changes occurring inside the CPMS should propagate automatically to every connected service.

Accurate operational data will become one of the strongest competitive advantages as charging networks become more interconnected.

Avoid Over-Building Against Draft Specifications

Although the long-term direction is well understood, several implementation details surrounding Unified Bharat e-Charge are still evolving.

Developers should therefore avoid hardcoding assumptions around message formats, certification workflows, commercial settlement mechanisms, or reservation policies before official specifications stabilise.

A modular architecture makes this considerably easier.

If Beckn connectors, authentication methods, or transaction schemas change, only the interoperability layer requires modification while the operational charging platform remains unaffected.

This approach balances readiness with practicality.

Instead of waiting for the ecosystem to mature, CPOs can begin building platforms that are adaptable by design.

---

Summary

UBC Component	What It Requires	Where It Fits in Existing CPMS Architecture
Beckn API Layer	Standardised discovery and transaction interfaces for interoperable applications	Sits above the existing CPMS as an external interoperability layer while OCPP continues managing chargers.
Real-Time Availability Exposure	Accurate operational status, pricing, connector availability, and charger health	Uses live operational data already collected through the OCPP backend and publishes it through Beckn-compatible services.
Slot Booking & Reservation	Reservation engine with configurable booking windows, expiry rules, and session validation	Extends the CPMS scheduling and session management capabilities rather than existing only inside the consumer app.
Payment Settlement Interoperability	Standardised transaction confirmation and settlement workflows across participating applications	Integrates with the billing and payment layer while exposing interoperable transaction status externally.

Unified Bharat e-Charge does not replace existing Charge Point Management Systems—it expands their role. Future CPMS platforms will continue managing charging infrastructure through OCPP while simultaneously exposing interoperable digital services through Beckn. Operators that adopt modular, API-first architecture today will be considerably better positioned as national interoperability initiatives mature.

For a broader understanding of India's EV charging software ecosystem, explore our guide to EV Charging Software Development in India, and for a deeper architectural discussion on backend operations, read our EV Charging Station Management Software India guide. Together, these articles provide the technical foundation that Unified Bharat e-Charge builds upon. If you're planning a Beckn-ready charging platform or modernising an existing CPMS, Pixbit scopes the architecture, interoperability strategy, and implementation roadmap during a single discovery session.