UPI-Based EV Charging Under UBC: What The 2026 Rollout Means For CPOs

UPI-Based EV Charging Under UBC

On May 12, 2026, at a national charging-infrastructure conference in Bengaluru, the Ministry of Heavy Industries confirmed India’s move toward UPI-based EV charging: Unified Bharat eCharge (UBC), built with Bharat Heavy Electricals Limited (BHEL) as the project implementation agency and NPCI BHIM Services Limited (NBSL) handling design and development. Union Minister H.D. Kumaraswamy called it, on stage, “UPI for EV charging.” The same event approved ₹503.86 crore in fresh PM E-DRIVE funding for 4,874 public chargers across eight states — useful context, but not the part that changes how CPOs operate. UBC is.

This post is written for CPOs and eMSPs deciding what UBC-readiness actually requires operationally — with enough of the driver-side mechanics to explain why it matters. It is deliberately not another protocol-comparison piece; we’ve already covered UPI vs. UEI and UEI vs. OCPI in depth elsewhere on this blog. This is the “what to actually do about it” layer that sits above those: what UBC is and the problem it solves, the BHIM-scan-and-pay flow drivers will use, how UBC relates to the Beckn Protocol and UEI, why OCPI roaming remains a separate and complementary layer, and the concrete steps to get a charging network UBC-ready.

What UBC Is And The Problem It Solves

Unified Bharat eCharge is not a new charging network, a new hardware standard, or a new wallet. It’s a national interoperability layer: a standard by which any BHIM-compatible app can discover a participating charger and any participating charger can accept a UPI payment, regardless of which CPO operates it. As of March 2026, India had roughly 27,700 public chargers installed under the PM E-DRIVE base, run by more than 40 independent CPOs — each of which built its own driver app, its own QR code format, and in many cases its own prepaid wallet. A driver moving between a mall charger on one network and a highway charger on another has historically needed two different apps, two logins, and two separate balances to top up.

The fragmentation cost, in practice

For a CPO, this isn’t just a driver-experience complaint — it’s a direct hit to session volume. Every driver who can’t find your charger in the app they already have open, or who abandons a session because they don’t want to download and fund a new wallet for a one-off top-up, is a session your network never captures. Utilization at good sites already runs well below theoretical capacity; a discovery layer that only reaches your own app’s installed base caps it further.

What actually changes under UBC

Your operations, pricing, and hardware don’t change. What changes is the front door: instead of routing every driver through your own app, you expose your charger catalog and payment endpoint through a standard interface that BHIM — and, in time, any other compliant app — can query directly. You keep your existing business model; UBC just adds a second, much larger discovery channel on top of it.

The BHIM-Scan-And-Pay Flow: How UPI-Based EV Charging Works For Drivers

The consumer-facing mechanics are deliberately simple — closer to a UPI merchant payment than a charging-app checkout:

1. The driver opens the BHIM app — no separate charging app to install.
2. The app queries the UBC network for nearby chargers; UBC-enabled stations from any participating CPO show up alongside the driver’s usual options.
3. The driver picks a charger and scans the QR code posted at the unit.
4. The session is authorized and charging begins.
5. Payment settles by UPI, directly from the driver’s bank account, when the session ends — no wallet top-up, no stored balance.

The operational detail worth noting is the last step: money moves bank-to-CPO, not driver-to-wallet-to-CPO. There’s no intermediary holding a float or taking a cut the way a closed prepaid wallet effectively does. That’s good for CPO cash flow, but it does mean your billing and reconciliation systems need to recognize a new settlement pattern rather than folding it into however you currently process in-app wallet payments.

How UBC Relates To The Beckn Protocol (And UEI)

UBC’s technical foundation is the Beckn Protocol — the same open-network architecture underneath ONDC, India’s e-commerce interoperability layer. Beckn defines two roles: a Beckn Application Provider (BAP), the consumer-facing app (BHIM, in UBC’s case), and a Beckn Platform Provider (BPP), the seller-side system — your charging network’s backend. A lightweight Beckn Gateway registry routes a driver’s “find a charger near me” query to relevant BPPs; once a match is found, the gateway steps out, and the actual session and payment happen directly between the BAP and the BPP.

Where this gets genuinely confusing is UBC’s relationship to UEI (Unified Energy Interface), the Beckn-based energy-sector interoperability concept the industry has been discussing for longer than UBC has existed. Public materials and official commentary don’t cleanly agree on whether UBC and UEI are the same initiative under two names or two related-but-distinct layers — and CPOs shouldn’t wait for a tidy taxonomy before acting. The practical way to read it: UBC is the UPI-native, NPCI/BHIM-integrated rollout of the broader Beckn/UEI open-network model for EV charging, not a rigid technical descendant of one over the other. We’ve unpacked the payment-layer distinction between UPI and UEI in more detail on UPI vs. UEI, and the architectural gap between UEI and OCPI in our explainer on what UEI actually is — both are worth reading alongside this one if your team is deciding where to spend integration effort first.

OCPI Roaming Is A Separate, Complementary Layer

It’s tempting to file UBC under “another roaming standard” next to OCPI, but they solve different problems at different layers. OCPI 2.2.1 is a backend-to-backend protocol: it lets a CPO’s system and an eMSP’s system exchange authentication tokens, location and pricing data, and session records (CDRs) so a driver registered with one network can authenticate and charge on another’s hardware. It’s the plumbing behind cross-network roaming, and we cover the mechanics of it in our UEI and OCPI key differences piece and our broader look at EV charging roaming and interoperability.

UBC sits a level above that plumbing. It’s the driver-facing discovery and payment layer — the equivalent of a UPI-style single interface for finding, starting, and paying for a session — rather than the backend handshake that makes cross-network authentication possible in the first place. A CPO that has already invested in OCPI compliance for roaming isn’t wasting that effort: it’s the same technical foundation — structured location data, real-time status, standardized session records — that a Beckn/UEI adapter for UBC will expect to already be in place. Think of OCPI as the CPO-to-CPO handshake and UBC/Beckn as the driver-to-network handshake; a mature charging business needs both, not one instead of the other.

What CPOs Need To Do To Become UBC-Ready

Formal UBC certification and registration flows hadn’t been publicly opened at the time of writing — public reporting describes an active pilot between the central government and early network partners, with APIs and onboarding steps expected to publish once that pilot concludes. That’s a reason to prepare now, not a reason to wait. Five things are worth doing in parallel:

1. Confirm your backend is genuinely OCPP-compliant

Reliable remote session start/stop, real-time status, and connector-level telemetry are the baseline any BAP integration — BHIM or otherwise — will need to trigger a charging session it didn’t originate.

2. Expose an OCPI 2.2.1 or Beckn/UEI adapter

These are the two live integration paths into an open-network layer today. Either gives a Beckn Gateway the token exchange, catalog sync, and session/CDR handling it needs to treat your network as a valid BPP.

3. Clean up catalog and pricing data

Beckn’s discovery layer surfaces exactly what your system reports — connector type, live availability, and tariff — network-wide, not just inside your own app. Stale pricing or availability data that was a minor annoyance inside a closed app becomes a visible, network-facing accuracy problem under UBC.

4. Rebuild reconciliation around direct UPI settlement

Bank-to-CPO settlement doesn’t behave like a prepaid wallet balance draining down. Billing and finance teams need a ledger that reconciles UPI-settled UBC sessions, OCPI roaming settlements, and any existing in-app payments as three distinct but unified income streams — not three separate spreadsheets.

5. Track the certification pipeline instead of guessing at it

Register interest where the ministry and NPCI make that possible, and use the wait to pressure-test your OCPP/OCPI layer in a sandbox rather than committing engineering time to a spec that hasn’t been finalized yet.

This is exactly the seam a payment and billing platform needs to sit across cleanly — one system reconciling OCPP session data, OCPI roaming settlements, and UPI-based payments into a single ledger, instead of three parallel books kept by three different teams. Built on top of a charging management system like YoCharge, that reconciliation runs per session automatically, so UBC becomes one more payment rail to plug in rather than a manual close-the-books exercise every billing cycle. Fleet operators managing electrified vehicles across multiple CPO networks face a related but distinct version of this problem — YoMobility’s breakdown of UBC for fleet operators covers that reconciliation angle from the fleet side.

Sources: Ministry of Heavy Industries — PIB press release, May 2026 | electrive.com, May 2026 | Beckn Protocol