OCPP and UPI: How EV Chargers in India Can Take Payments Without an App

Pull up to a public EV charger in India in 2026 and the hardest part is often not the charging. It is the paying. One network wants you to download its app and pre-load a wallet. Another takes a card the machine cannot read in the afternoon sun. A third has a faded QR sticker that opens a page which never loads. You just want to put two hundred rupees of electricity into your car and leave. This is the friction the Open Charge Alliance has been trying to kill with UPI, and it is worth understanding properly, because it changes how every charge point operator in India should think about payments.

We build and run PlugEV, an OCPP charging management system live on 40-plus chargers across two Indian cities, so we deal with this every day. When the Open Charge Alliance, the industry body that maintains the OCPP protocol, laid out its approach for taking UPI at chargers, we read it closely. This is the plain-English version: what they proposed, how it maps onto OCPP underneath, and, most importantly, what you can actually ship today versus what still needs a protocol upgrade most of India has not made yet.

Why EV charging payments are broken in India right now

The core problem is fragmentation. Every charge point operator built its own app with its own wallet, so a driver who uses four networks carries four apps and four pre-loaded balances they can never quite spend down. Roaming between networks barely works. The result is that a charger can be perfectly healthy and still fail to earn money, because the payment step defeated the driver before the electrons ever moved.

UPI is the obvious escape hatch. Every Indian phone already has a UPI app, nobody needs to be talked into using it, and a two hundred rupee transfer takes seconds. The question was never whether UPI belongs at a charger. It was how to wire it in so that paying actually starts a charge and stops it at the right amount, instead of just moving money into a bank account with no link to anything physical.

What the Open Charge Alliance actually proposed

The Open Charge Alliance sketched two ways to bolt UPI onto charging. Both start the same way, with a QR code on the charger that any UPI app can scan, and neither needs the driver to install an operator app. The difference is how much the charging system knows about the payment afterward. That single difference decides almost everything else, so it is worth walking both.

Option A: direct UPI, no app, nothing in the loop

In the direct model, the QR code on the charger simply encodes the operator's UPI ID (the VPA) plus the charger's own ID. The driver scans it with any UPI app, the app opens pre-filled with the operator as the payee, the driver types an amount, and pays. That is the entire flow.

The QR encodes a standard UPI deep link, something like upi://pay?pa=cpo123@hdfcbank&pn=CPO-Name&tr=EVSE1234-1, where pa is the operator's VPA, pn is the operator's name, and tr carries the charger reference. Scan it and money moves straight from the driver's bank to the operator's bank.

• Driver scans the charger QR with any UPI app, GPay, PhonePe, Paytm, or a bank app.
• The UPI app opens pre-filled with the operator's VPA as the payee.
• The driver enters the amount, say 200 INR, and confirms.
• The money moves from the driver's bank to the operator's bank. Done.

The appeal is obvious. It works with literally any UPI app, there is no operator app to download, and you can deploy it on any charger today, because the payment never touches the charging protocol at all. You could sticker a VPA QR on a charger this afternoon.

The catch is just as real. The charging system has no idea the payment happened. The money lands in the operator's account, but nothing tells the charger to start, nothing caps the session at the two hundred rupees paid, and refunding a half-used charge is a manual chore. Payment and charging become two ships passing in the night. That is fine for a supervised captive fleet, and painful for unattended public charging.

Option B: redirect to the operator's page, and close the loop

The redirect model fixes exactly that gap. Here the QR encodes a URL rather than a VPA, something like https://cpo.example.com/pay?charger_id=EVSE1234-1. The UPI app opens the operator's own web page, the driver enters an amount, and gets handed to a payment service provider (a PSP) to actually complete the UPI payment. Crucially, the PSP then notifies the operator's system when the money clears.

• Driver scans the QR, which opens the operator's payment page with the charger ID in the URL.
• The driver enters an amount and is forwarded to the PSP to pay by UPI.
• The PSP processes the payment and calls the operator's system back: 200 INR paid, for charger CS-001.
• The system now knows a specific charger was paid a specific amount, and can act on it.

Now the loop is closed. Because the operator's system learns that the payment succeeded and for which charger, it can start the session automatically, stop it when the paid amount runs out, and refund the balance if the driver unplugs early. Refunds are genuinely possible here, which they simply are not in the direct model. The price is that you now run a web page and a PSP integration, which is more to build and more to keep alive.

Where OCPP comes in: tying rupees to a real session

The redirect model only feels like magic because OCPP, the protocol between the charger and the operator's system, has messages built for exactly this. Here is the sequence the Open Charge Alliance walked through, lightly simplified.

1. Payment starts. After the QR hands the driver off to the operator page and then the CSMS with the charger ID, the charger can tell the CSMS a web payment has begun with NotifyWebPaymentStartedRequest(evseId, timeout), so the screen shows a processing state and the connector waits.
2. Driver authorizes. The driver approves the payment on the PSP page, say 12.34 INR, and the PSP confirms it with a reference such as PspRef = 4444.
3. CSMS starts the charge. The CSMS sends RequestStartTransactionRequest carrying an idToken of type DirectPayment, where the payment reference stands in for an RFID card, and the charger replies RequestStartTransactionResponse(Accepted).
4. The cap is set. The charger reports TransactionEventRequest(eventType = Started) and the CSMS answers TransactionEventResponse(transactionLimit.maxCost = 12.34). That one field is the whole trick: the amount paid becomes a hard ceiling on the session.
5. The charge stops itself. When the energy delivered is worth that cap, the charger ends the session on its own and reports TransactionEventRequest(eventType = Ended, triggerReason = CostLimitReached).

Read that last step again. The driver paid 12.34 rupees, got 12.34 rupees of electricity, and the session stopped itself. No app, no card, no attendant, no overcharge, no refund to process. That is prepaid charging done properly, and it is the reason the redirect model is worth the extra engineering.

“The amount paid becomes a hard ceiling on the session. Pay two hundred rupees, get two hundred rupees of charge, and the charger stops itself.”

The catch: those messages are OCPP 2.x, and India runs on 1.6-J

Here is the part the slides do not dwell on. NotifyWebPaymentStartedRequest, the DirectPayment token type, and transactionLimit.maxCost are not part of OCPP 1.6-J, the version that roughly 95 percent of chargers shipping in India actually speak. They belong to the newer 2.x line, and the native payment pieces in particular to OCPP 2.1, which folded in first-class payment support. OCPP 2.0.1 is still under a fifth of the installed Indian fleet, and 2.1 is newer again.

So the fully native, protocol-level version of the redirect model is, for most Indian operators, a couple of years out. We wrote a whole piece on when a 1.6-J operator should even bother moving to the next version, and for most the honest answer today is not yet. If you are weighing that jump, start with our OCPP 2.0.1 migration playbook.

What you can actually ship on 1.6-J today

The good news is the practical heart of all this: you do not need OCPP 2.1 to take UPI at a charger. You need to bridge the payment and the session yourself.

Direct UPI (Option A) works on any charger regardless of OCPP version, because it never touches the protocol. If you can live without automatic session control, you can put a VPA QR on a 1.6-J charger today and start collecting.

To get the closed loop of Option B on 1.6-J, you rebuild the smart part in your own backend. The pattern we use looks like this:

1. Driver scans a QR that opens your page, or a hosted UPI checkout, with the charger ID baked into the link.
2. The driver pays. Your payment provider fires a webhook to your backend confirming the amount and which charger it was for.
3. Your backend starts the charge by calling OCPP 1.6-J RemoteStartTransaction on that charger, using the payment reference as the id tag.
4. You enforce the cap yourself. Because 1.6-J has no transactionLimit.maxCost, you watch the MeterValues streaming in, and when the delivered energy is worth what the driver paid, you send RemoteStopTransaction.

It is more moving parts than a single OCPP field, but it works on the hardware that is actually on the ground in India, and it is exactly the kind of glue an OCPP CSMS has to provide anyway. The RFID flow most operators already run is the same shape, with a card swipe instead of a payment as the trigger to start.

Direct UPI or redirect: which should an operator pick?

There is no single right answer. It depends on the site and the risk you can carry.

Reach for direct UPI when the chargers are AC and slow, the amounts are small, the site is captive or at least semi-supervised, and you want zero backend and no PSP fees beyond UPI itself. You are accepting that there is no automatic session control and that refunds are manual.

Reach for the redirect model, or its 1.6-J backend equivalent, when the chargers are DC and fast, the sites are unattended and public, and you need the session to stop at the amount paid, refund cleanly, and tie every rupee to a session for accounting. Most serious public networks end up here, because unattended fast charging without a cost cap is how you spend your evenings refunding angry drivers by hand.

The part nobody puts on a slide: reconciliation and GST

Getting the money in is half the job. Matching it to sessions, surviving retries, and invoicing it is the other half, and it is where most homegrown systems quietly leak.

UPI settles a couple of days later, payment webhooks retry, and a driver on patchy signal will tap pay twice. Without idempotency you either start two sessions or bill one driver twice. We key every payment event by its provider reference in Redis, so a repeated webhook is a no-op and a reconnecting charger or a retried callback never double-charges. The mechanics are the same ones in our guide to Razorpay webhooks, idempotency, and reconciliation, and the wider view of what each payment rail costs is in our breakdown of accepting payments in India.

Then there is tax. Every paid charge is a taxable supply, and above the turnover threshold you owe a proper e-invoice with an IRN, not just a receipt. We fold that into the billing engine so a finished session produces a GST e-invoice automatically. Skip it and you are hand-reconciling a spreadsheet against your bank statement at year end.

How we handle it at PlugEV

For context on where all this comes from: PlugEV is our OCPP 1.6-J charging management system, in production since early 2025 on 40-plus chargers across two Indian cities. Payments run through UPI and cards on Razorpay, sessions are rated continuously into paise, and a completed charge produces a GST invoice on its own. Idempotency keys in Redis keep a retry or a reconnecting charger from ever billing a driver twice.

We run the closed loop today with the 1.6-J backend bridge described above, not native OCPP payment messages, because that is what the deployed hardware supports. Native DirectPayment and transactionLimit.maxCost sit on our 2.0.1 and 2.1 roadmap, alongside the certificate-based security we wrote up separately. If you want the full build story, it is in our OCPP CSMS write-up and the PlugEV case study. And if you are still deciding what OCPP even commits you to, start with our plain explainer on what OCPP is.

Common questions about OCPP and UPI payments

Do EV charging UPI payments need OCPP 2.0.1 or 2.1?

Not for the simple case. Direct UPI, where a QR on the charger opens any UPI app to pay the operator, needs no OCPP payment features at all, because the money never touches the protocol. You only need the newer OCPP 2.x payment messages if you want the charger to start automatically, cap the session at the amount paid, and refund the rest natively. On OCPP 1.6-J you can get the same result by handling that logic in your own backend.

Can a driver pay at a charger with any UPI app?

Yes, that is the whole appeal. If the QR encodes the operator's VPA (the pa field in a upi://pay link), any UPI app, GPay, PhonePe, Paytm, or a bank app, can pay it. There is no operator app to download and no wallet to pre-load.

How does the charger know the payment went through?

In the direct model, it does not, which is its main weakness. In the redirect model, the driver pays through a payment service provider, and the PSP notifies the operator's system, which then starts the session. On native OCPP 2.x this is the NotifyWebPaymentStarted and DirectPayment flow; on 1.6-J it is a payment webhook into your backend followed by a RemoteStartTransaction.

What happens to the money if I unplug before the charge finishes?

That is exactly what the redirect model solves and the direct model does not. When payment is linked to the session, the operator caps the charge at the amount paid and refunds any unused balance. With a plain direct-UPI transfer, the operator has your money and no automatic link to the session, so any refund is manual.

Is this live in India yet?

Direct UPI at chargers is deployable today, and some operators already do it. The fully native OCPP 2.x version is newer and depends on hardware most of India has not deployed, since the fleet is still mostly OCPP 1.6-J. The practical answer for 2026 is direct UPI for simple sites, and a backend-bridged closed loop on 1.6-J for serious public charging.