Payments and settlement for EV charging in India

Charging is one of the few retail transactions where the amount owed is unknown when the customer commits to buy. A driver plugs in, and neither of you knows whether the session will cost forty rupees or four hundred. Everything difficult about charging payments follows from that single fact.

This guide covers the money path end to end: how a driver pays, how the operator collects, how refunds are handled, what GST does to your pricing, and how the site partner’s share is calculated and paid. It is written for India, where UPI has made some of this much easier and one part of it considerably harder.

The four ways a driver can pay

Every charging network in production uses at least two of these, usually three. They are not interchangeable — each carries different risk and different working capital.

The complication specific to India is that UPI, which is how most drivers would prefer to pay, has no widely available pre-authorisation equivalent for this use case. You either collect a fixed amount up front and reconcile afterwards, or you let the session run and collect at the end, accepting that a small fraction of drivers will walk away without paying.

Authorisation, capture and the gap between them

For card payments the sequence is a hold, then a capture. The hold is for an estimated maximum — a figure you choose — and the capture is for the actual amount once the session ends. Three decisions matter here.

1. 01How much to hold. Too little and a long session exceeds it, leaving you short. Too much and the driver sees an alarming figure blocked on their card and does not come back. Estimating from connector power and a realistic session length, per site rather than network-wide, is far better than a flat number.
2. 02How long the hold survives. Authorisations expire, typically within a few days. A session that fails to capture before expiry becomes an uncollectable receivable, and the driver may never learn they were not charged.
3. 03What happens when capture fails. It will, occasionally. The session must move to a defined state — not silently marked paid, and not silently forgotten — and that state has to appear on someone’s work queue.

The failure mode to design against is the one where the charger delivered energy, the meter recorded it, the session closed correctly, and no money was ever taken. It does not announce itself. It shows up as a slow, unexplained gap between energy delivered and revenue collected, and by the time anyone investigates it is months old.

Metering, rounding and the numbers that must agree

The amount charged has to be derived from the meter, not from an elapsed-time estimate or the charger’s reported power. Meter start and meter stop, both recorded, with the difference being the billable energy. Anything else will eventually disagree with a driver who was watching their own vehicle’s display.

• Record the meter values with the session, permanently. They are the evidence in any dispute, and disputes arrive months later.
• Round once, at the end, to two decimal places — never at each intermediate step, which introduces drift you cannot explain.
• Snapshot the tariff onto the session when it starts. A session priced at ₹18 must still show ₹18 after someone changes the tariff to ₹20 next week.
• Reconcile daily: energy delivered, amount billed, amount collected. Three numbers, one report. A gap on day one is a bug; a gap discovered at month end is an investigation.

Refunds, and why they are unavoidable

You will refund drivers. A charger will stop mid-session, a session will bill for energy the vehicle did not take, a driver will be charged twice by a retried payment. The question is not whether but how quickly and with how much argument.

A workable refund process has four properties. It is initiated from the session record rather than from the payment gateway’s own dashboard, so the reason is captured alongside the money. It is permissioned separately from ordinary operations, because refunds are the obvious internal fraud vector. It is capped — full or partial, but never more than the session collected. And it is idempotent, so a retried click does not refund twice.

GST, and the decision that has to be made before launch

Charging revenue attracts GST, and the single most consequential decision is whether your displayed price is inclusive or exclusive of it. This must be settled before the first driver sees a price, because changing it afterwards is either a price rise or a margin cut, and both are visible.

• Public retail charging is almost always quoted GST-inclusive. Drivers compare the number on the app to the number at a fuel pump, and a figure that grows at checkout costs you the session.
• Fleet and B2B contracts are usually quoted exclusive, because the counterparty reclaims input credit and expects to see the tax as a line.
• Whichever you choose, the tax must appear as a separate line on the receipt. A receipt that shows only a total is not usable by a business customer.
• Site partner revenue share is calculated on the net amount, not the gross. Getting this wrong overpays every host by the tax rate, and it is discovered during an audit rather than during a reconciliation.

Paying the site partner

If you operate on somebody else’s land, part of every session belongs to them. The mechanics of that are simple. The disputes are not, and they almost always come from ambiguity about the base rather than disagreement about the percentage.

A settlement statement should be derivable from the session records without a spreadsheet in between. For each period: sessions, energy, gross revenue, tax, net revenue, the contracted rate, the amount owed and the amount paid. Each line traceable to the session that produced it.

Name every one of these in the agreement, in or out. The list takes ten minutes to write and prevents the conversation entirely.

Effective dates, never retroactive edits

Commercial terms change. A host renegotiates, a tariff is revised, a discount ends. Every one of those changes must apply from a date forward, and no system should permit editing a term that a paid statement was already calculated from.

The reason is not theoretical. Once a statement has been issued and settled, a retroactive edit silently restates history. The host’s copy and yours no longer agree, neither of you can reconstruct which version was correct, and the only remedy is to recompute several months of settlements by hand. Systems that allow it produce this outcome eventually, without exception.

What to reconcile, and how often

Three reconciliations, at three cadences, catch almost everything.

None of these is difficult once the underlying records are trustworthy. All of them are impossible if the session record does not carry its own meter values, its own tariff snapshot and its own payment reference — which is why those three fields matter more than any report built on top of them.