On this page · 13 sections
- The four systems behind one "start charging" button
- Decision 1: which OCPP version you commit to
- Decision 2: own the CSMS or rent it
- Decision 3: payments, when the amount is unknown at the start
- Decision 4: roaming, and whether you need it yet
- Decision 5: uptime is a software property
- Decision 6: what you do with driver data
- The India context that changes the build
- What a competent build looks like
- How we work on this at eCorpIT
- FAQ
- How eCorpIT can help
- References
Summary. India has 52,718 public electric vehicle charging stations, of which 16,561 carry fast chargers for cars, according to the reply Minister of State for Heavy Industries Bhupathiraju Srinivasa Varma gave in the Lok Sabha on 21 July 2026. The public money behind that build-out is still flowing: ₹912.50 crore was allocated for public charging stations under FAME-II and ₹2,000 crore under PM E-DRIVE, a scheme notified on 29 September 2024 with a total outlay of ₹10,900 crore. Setting up a charging station is an unlicensed activity in India, so the barrier to entry is not the electricity. It is the software. A driver who cannot start a session at a working charger records that as a broken charger, and the failure is almost always in the protocol layer, the payment pre-authorisation, or the session state machine.
This is a build guide for the software side of a charging network: which OCPP version to commit to, whether to own the central system, how to handle payments when the final amount is unknown at the start, when roaming is worth the integration, and what actually causes downtime.
The four systems behind one "start charging" button
An EV charging product is four pieces of software, and teams routinely scope only the last one.
The charge point firmware speaks OCPP to a server. You rarely write it, but you inherit its bugs and its version.
The Charge Point Management System, or CSMS, is the server the charger connects to. It authorises sessions, pushes configuration, receives meter values, and holds the state machine that decides whether a connector is available, occupied, faulted or reserved.
The driver app is the part users see: find a charger, check availability, start a session, pay, see the receipt.
The settlement layer reconciles energy delivered against money captured, handles refunds, and produces the reports a charge point operator needs for tariffs and GST.
Uptime is a property of the second system, not the third. A network can have flawless hardware and an app that fails every third session because the CSMS lost the WebSocket and never resynchronised its connector state.
Decision 1: which OCPP version you commit to
The Open Charge Point Protocol is maintained by the Open Charge Alliance. OCPP 2.1 was released in January 2025 and is backwards compatible with OCPP 2.0.1. The Alliance has since published Edition 2 of both specifications, with parts 5 and 6 carrying the certification profiles and test cases, alongside an errata document dated April 2026.
| Version | What it gives you | When to choose it |
|---|---|---|
| OCPP 1.6J | The widest installed base of Indian hardware | Retrofit networks, mixed vendor fleets |
| OCPP 2.0.1 | Device model, improved security profiles | New builds where vendors certify for it |
| OCPP 2.1 | ISO 15118-20 bidirectional transfer, DER control block, improved smart charging | V2X plans, grid-service revenue, greenfield |
| OCPP 2.1 Edition 2 | Certification profiles and test cases in parts 5 and 6 | Anyone writing a procurement spec |
| Mixed 1.6J and 2.x | Two code paths, two state machines | The default reality, not a strategy |
The practical rule: choose the version your hardware vendors will actually certify against, then write the procurement spec against the Edition 2 test cases so certification means something at acceptance. The mistake is committing to OCPP 2.1 in a slide, buying 1.6J chargers because they were available, and discovering that half your smart-charging roadmap needs firmware nobody will ship.
OCPP 2.1 matters most if bidirectional power is on your roadmap. It adds a functional block for bidirectional charging to enable vehicle-to-everything energy flows, and a distributed energy resource control block. If your business case includes selling grid services rather than only selling kilowatt hours, that block is the reason to move.
Decision 2: own the CSMS or rent it
This is the decision that most changes cost and control, and there is no universally correct answer.
Renting a CSMS gets you to market in weeks and offloads OCPP conformance to a vendor who has already fought it. You pay per charge point per month, and you inherit their roadmap, their tariff model and their data export.
Owning the CSMS means you write the OCPP server, the state machine, the tariff engine and the operational tooling. It costs more up front and it is the only route to a differentiated product if your business is charging rather than hosting chargers.
The middle path works for most Indian operators under about 500 charge points: rent the CSMS, own the driver app and the settlement layer, and keep a clean abstraction between them so migration stays possible. Own the customer, rent the protocol. Whichever route you take, insist on raw OCPP message logs. Without them you cannot diagnose a failed session, and "the charger was faulty" becomes unfalsifiable.
Decision 3: payments, when the amount is unknown at the start
Charging breaks the normal ecommerce flow. You authorise before you know the amount, and you capture after energy has flowed. Every payment design decision follows from that.
Pre-authorisation with later capture is the standard model: block an amount that covers a plausible worst-case session, then capture the actual value. The user-facing consequence is a hold on their account, and in India that hold generates support tickets from customers who see money missing.
A wallet model avoids the hold. The driver tops up, the session debits the balance, and reconciliation is internal. It moves the friction to onboarding rather than to every session, and it gives you float, but the balance is a liability you must be able to refund.
UPI is the payment rail Indian drivers expect, and its collect-request flow does not map cleanly to authorise-then-capture. Most Indian networks land on a wallet funded by UPI, with cards used for pre-authorised sessions where a hold is acceptable.
Three failure modes are worth designing against explicitly. A session that starts but never receives a stop transaction leaves an open authorisation and an angry customer. A meter value stream that stops mid-session leaves you billing from the last known reading. And a refund path that requires manual approval turns a ₹200 dispute into a support cost larger than the transaction.
Decision 4: roaming, and whether you need it yet
Roaming lets a driver registered with one provider charge on another network. The protocol is the Open Charge Point Interface, maintained by the EVRoaming Foundation, which connects charge point operators and eMobility service providers either bilaterally or through roaming hubs. The current version is OCPI 2.3.0, which is compliant with EU NAP requirements under AFIR, adds vehicle types for locations, and carries optional payment terminal and booking modules. OCPI 3.0 exists in draft.
| Question | If yes | If no |
|---|---|---|
| Do drivers ask for chargers you do not own? | Integrate OCPI | Defer |
| Is your network under ~50 sites? | Defer roaming, fix discovery | Defer |
| Do you sell to fleets crossing city boundaries? | OCPI is table stakes | Defer |
| Can you settle inter-operator payments monthly? | Bilateral OCPI works | Use a hub |
| Do you need booking or reservation? | OCPI 2.3.0 optional module | Build in-app only |
Roaming is an integration cost that pays back only when a meaningful share of your users need chargers you do not operate. Before it is worth building, a more valuable fix usually exists: accurate real-time availability in your own app. A driver who arrives to find the connector occupied has the same experience as a driver who could not roam.
Decision 5: uptime is a software property
Charge point operators quote uptime, and drivers experience something different. The gap is where the engineering work is.
Connectivity is the first cause. Chargers in Indian basements and highway sites sit on weak 4G. A CSMS that treats a dropped WebSocket as a faulted charger will show phantom outages; one that never times out will show phantom availability. Both are wrong in the app.
The session state machine is the second. Start and stop are not symmetric: a start can fail after the charger has already energised, and a stop can be lost while the session is still running. Every state transition needs an idempotent handler and a reconciliation job that compares CSMS state against the charger's own transaction list.
Configuration drift is the third. Fleets accumulate chargers on different firmware with different OCPP configuration keys. Without an inventory that records firmware version, OCPP version and configuration per charge point, a fix that works on one site silently fails on another.
The honest engineering position: most "charger down" reports are software state, not hardware. Instrument the session funnel from tap to first kilowatt hour and the real failure point becomes obvious within a week.
Decision 6: what you do with driver data
A charging app collects location, vehicle identity, payment identifiers and a movement history precise enough to infer where someone lives and works. That is personal data under Indian law and it deserves a deliberate design rather than a default.
Section 8 of the Digital Personal Data Protection Act, 2023 makes the Data Fiduciary responsible for compliance in respect of any processing undertaken on its behalf by a Data Processor, irrespective of any agreement to the contrary. If your CSMS is a vendor and your analytics is a third party, the obligation is still yours. Build one register of what leaves the app, to whom, for what purpose and for how long, and keep session history retention short enough to defend. Our DPDP engineering playbook for Indian startups sets out the wider structure.
The India context that changes the build
Three policy facts shape what you build here rather than in Europe.
Charging is an unlicensed activity. You do not need a distribution licence to operate a public charging station, which is why the operator field is crowded and why differentiation sits in software rather than in permits.
The Ministry of Power has issued the Guidelines for Installation and Operation of Electric Vehicle Charging Infrastructure 2024, which set standards for a connected and interoperable charging network and cover battery swapping alongside charging. Interoperability is a stated policy goal, so building a closed network is running against the direction of travel.
The subsidy money is specific and dated. ₹912.50 crore was allocated under FAME-II for public charging stations, and ₹2,000 crore is allocated under PM E-DRIVE, notified on 29 September 2024 with a ₹10,900 crore outlay covering roughly 28.30 lakh vehicles. FAME-II Phase II ran from 1 April 2019 to 31 March 2024 with ₹11,500 crore of budgetary support and backed around 16.72 lakh electric vehicles, plus 5,197 electric buses deployed as on 30 June 2026. Electric cars sit outside PM E-DRIVE and are supported instead through the Production Linked Incentive scheme for automobiles, which pays 13% to 18% on determined incremental sales of advanced automotive technology vehicles to eligible manufacturers.
Two build consequences follow. Fleet and bus operators are a larger near-term software market than private car drivers, because the subsidy has concentrated there. And any product that assumes a single national tariff model will break, because operators price differently site by site.
What a competent build looks like
For a charge point operator starting now, the sequence that avoids the most rework:
- Write the hardware procurement spec against the OCPP version you will actually run, referencing the Edition 2 certification profiles and test cases.
- Stand up the CSMS, rented or owned, with raw message logging switched on from day one.
- Build the driver app against a stable internal API, not against the CSMS vendor's API, so the vendor stays replaceable.
- Ship the wallet before the pre-authorisation flow if your users are UPI-first.
- Instrument the session funnel: tap, authorisation, start command accepted, first meter value, energy delivered, stop, capture. Alert on the drop between start accepted and first meter value, because that is the one drivers report as a broken charger.
- Add OCPI roaming only when your own network is reliable enough that borrowing someone else's will not make your app look worse.
- Keep a per-charge-point inventory of firmware version, OCPP version and configuration keys.
The engineering judgement worth stating plainly: the hard part of a charging product is not the app screens, it is agreeing what a session is across four systems that each think they own it.
How we work on this at eCorpIT
eCorpIT is a Gurugram technology consulting firm founded in 2021, assessed at CMMI Level 5 and MSME certified, with partnerships including AWS, Microsoft and Google. Our senior engineering teams build the driver app, the settlement layer and the integration work around a CSMS, and we run the OCPP conformance testing that acceptance depends on.
Typical engagements start with a two to three week discovery: protocol audit of the chargers you already have, a session-funnel instrumentation plan, and a build-or-rent recommendation for the CSMS with the migration path written down. From there we build in fortnightly increments against a stable internal API, so the app team and the platform team are not blocked on each other.
We work in Flutter and native Android and iOS depending on the field-service requirements, since charge point technician apps often need hardware access that a shared codebase complicates. Related practice pages: Flutter app development, Android and Kotlin app development, and logistics and supply chain app development for fleet-side work. We design these systems aligned with Digital Personal Data Protection Act 2023 requirements.
FAQ
How eCorpIT can help
eCorpIT builds the software layer of EV charging networks: driver apps, settlement and reconciliation, CSMS integration, and the OCPP conformance testing that makes hardware acceptance meaningful. Our senior engineering teams start with a protocol audit and a session-funnel instrumentation plan, so you find out where sessions actually fail before you commit to a platform. We design these systems aligned with Digital Personal Data Protection Act 2023 requirements, and we keep the CSMS replaceable behind your own API. Tell us how many charge points you run and which OCPP versions are in the field at /contact-us/.
References
- India has over 52,700 public EV charging stations, including 16,561 fast chargers for cars - The Tribune / ANI, 21 July 2026, reporting the Lok Sabha reply and the scheme allocations.
- OCPP protocols - Open Charge Alliance, the protocol family and current versions.
- New editions of the OCPP 2.1 and 2.0.1 now available - Open Charge Alliance, Edition 2, parts 5 and 6, and the April 2026 errata.
- OCPP 2.0.1 - Open Charge Alliance, the 2.0.1 specification.
- Download OCPP - Open Charge Alliance, specification downloads and editions.
- Open Charge Point Protocol - Open Charge Alliance, the open standards overview.
- OCPI - EVRoaming Foundation, the roaming protocol and its purpose.
- OCPI downloads - EVRoaming Foundation, published OCPI versions.
- EVRoaming Foundation - the body maintaining OCPI.
- The complete OCPI guide - AMPECO, version history and module detail for OCPI 2.3.0.
- OCPI protocol explained - Virta, the CPO and eMSP roles in roaming.
- Digital Personal Data Protection Act, 2023, Section 8: general obligations of Data Fiduciary - India Code, official text.
Last updated: 22 July 2026.
