Unified Bharat e-Charge (UBC), Explained for EV Operators

Ask anyone who drives an electric car in India what the worst part of public charging is and you rarely hear about range. You hear about apps. One network for the highway, another for the mall, a third for the office car park, each with its own login and its own prepaid wallet holding a few hundred rupees you will probably never see again.

Unified Bharat e-Charge, UBC for short, is the government's attempt to end that. It launched around Independence Day 2026, and the first thing a driver notices is simple: the BHIM app now finds chargers, and you pay for the session over UPI the way you pay for anything else. No operator app. No wallet top-up.

We build charging software. PlugEV, our OCPP charging management system, has been in production since January 2025, so we read UBC less as drivers and more as the people who would have to wire a backend into it. This post is that reading: what UBC is, how it fits next to OCPP and OCPI, and what an operator's software has to do to take part. Where the public material runs out, we say so instead of guessing.

What Unified Bharat e-Charge actually is

UBC is a national interoperability layer for public EV charging. It is not a charging network of its own and it does not own a single charger. It is a shared set of rules that lets any participating app find any participating charger, start a session on it and pay for it, whichever company happens to run that charger.

Three public bodies sit behind it. The Ministry of Heavy Industries backs it as the National Unified Hub for EV Charging, something the PM E-DRIVE scheme has been pointing towards for a while. BHEL is the project implementation agency. NPCI BHIM Services, the NPCI arm that runs the BHIM app, was brought in to design and build the platform, and the underlying digital public infrastructure came from the Network for Humanity team. The protocol underneath is Beckn, the same open protocol ONDC runs on.

For a driver it looks like this today: open BHIM, find a UBC-enabled charger, scan the QR code on it and pay from your bank account through UPI. Here is how the rollout has gone so far, as of late September 2026:

• 15 August 2026. UBC launched by MHI, BHEL and NPCI, with EV charging showing up inside the BHIM app.
• Mid August. Pulse Energy announced itself as one of the first certified technology enablers, with more than 10,000 chargers from over 100 operator partners connected to BHIM UPI.
• 3 September. The Ministry of Heavy Industries said the pilot phase had begun across Maharashtra, Karnataka, Delhi-NCR, Haryana and Rajasthan.

UBC does not replace OCPP. It sits on top of it.

The first question most people ask is whether UBC is a new protocol for chargers. It isn't. There are three layers in play and each one does a different job:

• OCPP is how a charger talks to its own operator's backend: BootNotification, StatusNotification, StartTransaction, MeterValues and the rest. Your chargers keep speaking it exactly as they do now. If you want the wire format, we walked through the eight messages that matter.
• OCPI is how two operators' backends roam with each other, usually under a bilateral agreement. One lets the other's customers charge, and they settle up later.
• UBC sits above both. It is the public discovery and ordering layer, a national network where apps ask for chargers and operators answer.

So a UBC session still ends with your backend sending a RemoteStartTransaction to a charger over OCPP. UBC changes who asked for it and how the money arrives. Nobody needs to reflash charger firmware for this, which is good news for anyone with a yard full of 1.6-J hardware.

Beckn, explained for people who already know OCPP

If your background is OCPP, Beckn will feel familiar in places and odd in others. It is an open protocol for commerce between strangers: a buyer-side app and a seller-side platform that have never signed a contract with each other, finding each other through a shared registry.

There are three kinds of participant. A BAP (Beckn Application Platform) is the buyer side, the app the driver holds, and BHIM is the first one here. A BPP (Beckn Provider Platform) is the seller side, which for UBC means a charge point operator or a platform acting for one. Between them sit a gateway and a registry, which handle discovery and who is who, then get out of the way. The order itself runs directly between the BAP and the BPP.

Every Beckn call is asynchronous. The app sends search and gets an acknowledgement straight away; the real answer comes back later as a separate on_search call to the app's own endpoint. The same pattern repeats through the order with select, init and confirm, then status, update, cancel and track while it runs. Requests are signed, so every participant has keys registered with the network. If you have ever handled an OCPP CALL and CALLRESULT pair, think of it as the same idea stretched across two companies and an HTTP callback.

That is the general Beckn shape, and it is well documented. What we have not seen published yet is the full UBC profile on top of it: which charger attributes go in a catalogue, how a tariff is expressed, which field carries the connector and its QR identity. The early explainers say APIs and registration flows are to be published for wider operator onboarding. Until they are, anyone giving you field-level detail on UBC is either working from a pilot document or guessing.

How a UBC order maps onto the OCPP you already run

This is how we expect a UBC session to land on an operator's charging system. The Beckn half is the standard flow. The OCPP half is what your backend already does for your own customers.

1. Discovery. A driver searches in BHIM, the network routes the search to operators, and your platform answers with chargers near them. The only honest source for that answer is the last StatusNotification from each connector. If your backend thinks a connector is Available when it went Faulted twenty minutes ago, UBC will send a driver to a dead charger with the government's name on the screen.
2. Quote. select and init are where the driver sees a price. That price has to come out of the same tariff engine that bills everyone else, time-of-day rates and idle fees included. Our tariff and billing write-up explains why that is harder than it sounds.
3. Confirm and pay. The order is confirmed and the driver pays over UPI. In the BHIM flow that means scanning the charger's QR and paying from a bank account.
4. Start. Your backend turns the confirmed order into a RemoteStartTransaction for the right connector. The idTag is no longer someone's RFID card. It is something you mint for the order, and your backend has to accept it when the charger comes back asking to Authorize.
5. Track. While the car charges, MeterValues feed the status updates so the app can show energy delivered and the running cost.
6. Stop and settle. The driver stops from the app, you send RemoteStopTransaction, StopTransaction brings back the final meter reading, and the bill is worked out from that reading rather than an estimate.

Nothing on that list needs a new charger. Every step is software, and nearly all of it lives in the operator's backend.

What an operator's software actually has to get right

Plenty of Indian charging backends were built for exactly one app: their own. UBC exposes them to a public caller that doesn't know their quirks and won't forgive them. From where we sit, these are the things that decide whether a UBC integration works once real drivers show up:

• Status you can trust. Chargers that fall off the network need to be marked unavailable quickly, and a missed heartbeat should count as offline. Discovery is only as good as this.
• Tariffs as data. If your prices live partly in an admin screen and partly in code nobody wants to touch, they need to become something that can be published and quoted the same way every time.
• Sessions that don't need your app. Remote start keyed to an order, not to a logged-in user of your own app. Operators whose whole flow assumes their app is in the loop will feel this one most.
• Idempotency everywhere. Beckn callbacks, payment webhooks and OCPP retries can all arrive twice. One order has to start one session and produce one charge. We covered the same trap for UPI payments at chargers.
• Reconciliation and GST. A UBC session is still your taxable supply. It needs an invoice, above the threshold an e-invoice with an IRN, and the money that settles has to match the sessions that actually ran.

None of this is exotic. It is the same list any serious charging network has to get right sooner or later. UBC just takes away the option of getting it wrong quietly.

Join through an enabler, or integrate directly?

There are two ways in. You can connect through a certified technology enabler, a platform that has already built the UBC side and talks to your chargers or your backend for you. Pulse Energy was first through that door and others will follow. Or you can build the provider side yourself and plug your own backend into the network.

Our view, for what it's worth. If you run a few dozen chargers and your backend is someone else's product, go through an enabler. You get onto the map in the pilot states quickly and you see what UBC traffic actually looks like before spending engineering time on it. If you own your charging software, run a few hundred chargers, or care how your prices and brand show up in someone else's app, start planning a direct integration now. On top of a CSMS that is already in good shape it is a bounded piece of work. On top of one that isn't, it will drag every old problem into the light.

Either way, the list in the previous section stays yours. An enabler can relay a start command. It cannot make a faulted charger report itself honestly.

What is still unclear

UBC is a few weeks old and a lot of what operators will want to know isn't public yet. These are the questions we would want answered before promising anything to a client:

• What an operator pays to take part, if anything, and who carries the UPI charges.
• How fast money settles to the operator, and what the reconciliation data looks like.
• What certification a direct integration needs and how long it takes.
• Whether other apps will join as buyer platforms after BHIM, which is exactly what Beckn is designed to allow.
• Who handles the dispute when a driver has paid and the charger never started.

We will update this post as the specification and the onboarding rules come out.

Where we are coming from

PlugEV, our OCPP 1.6-J charging management system, runs on a NestJS backend and has been in production since January 2025, now across 40-plus chargers in two Indian cities. The pieces UBC leans on hardest are the ones we already had to build for that network: live connector status, UPI collection, tariffs, and a GST invoice for every session. So when we say the hard part of UBC is the charging system underneath rather than the Beckn messages on top, that is where it comes from.

If you are newer to the charger side of all this, our plain-language OCPP explainer is a better place to start than this post.