RFID Card For EV Charging Vs Driver Apps Vs Plug & Charge: What Fleets Should Issue

If you are an individual EV owner looking for an RFID card for EV charging at your nearest public charger, stop here: your network’s customer care will issue you one, and that is the whole job. This post is written for fleet managers whose drivers charge away from the depot — the taxi operator whose 60 cars top up at whatever DC charger is nearest at 2 pm, the 3PL whose vans plug in mid-route in a city where you own nothing.

For that reader, authorisation is the control point where charging spend either stays governed or leaks. What the driver presents at the charger decides what the charge point operator (CPO) records — and therefore what you can attribute, challenge or recover at invoice time. No finance discipline downstream rebuilds data you never captured. If your question is instead how charging should be funded at all, that business-model view lives in our EV fleet payments strategy post; this one covers the ten seconds at the charger.

The Four Ways A Fleet Driver Can Start A Public Charging Session

Strip the branding away and every public session begins identically: the charge point asks who this is and who pays, and the answer arrives as a token — a string the charger reads and the operator’s back end validates against an account. Which token you put in a driver’s hand decides everything in your cost data downstream.

1. The driver’s personal app or a UPI QR code. The driver pays from their own account and claims it back. Zero setup, and it is how most Indian fleets begin — but the transaction sits outside your systems, and the operator’s record identifies a consumer, not your van.

2. A shared depot RFID card. One card in the office drawer or the glovebox, used by everyone. The fleet is billed directly, which feels like control. The next section is why it is the opposite.

3. Per-driver tokens. One card — or one fleet-app login — per driver, all under a single fleet billing account. Slightly more administration, and the only option that produces attributable data from day one.

4. Plug & Charge. The vehicle authenticates itself over ISO 15118 the moment the cable is connected — no card, no app. Elegant, and for a mixed Indian fleet on public infrastructure, not yet the everyday answer.

The five columns that decide your cost data. Everything else about a charging credential is preference.

Why A Shared RFID Card For EV Charging Destroys Per-Vehicle Cost Data

Start with the record itself, because that is where the damage is done. Under OCPI — the roaming interface most Indian CPO-to-platform integrations follow — the object that becomes your invoice line is the charge detail record, and the identity it carries is a CdrToken: a uid, the token type, a contract ID and the issuing party’s code. The specification describes that uid plainly as “the field used by CPO system (RFID reader on the Charge Point) to identify this token.”

Read what is absent. There is no vehicle field. No registration number, no driver name, no cost centre. Your van’s number plate never travels to the charger and the CPO has no idea it exists. The only identity in the record is the credential that was presented — so the credential is your accounting dimension, whether you designed it that way or not.

Put one card in front of 30 vans and every session in the month resolves to the same identity. Attribution then has to be reconstructed afterwards by matching session timestamps and charger locations against telematics. That reconstruction works fine for isolated sessions and fails precisely where the money is: two of your vehicles at the same hub inside the same half hour, which for a delivery fleet is the same mid-afternoon window every single day. The ambiguous sessions are not randomly scattered — they cluster on your busiest, most expensive days.

Four things quietly disappear with them. Per-vehicle cost per kilometre, so van 12 can never be compared with van 19. Energy consumption drift, the earliest cheap signal that a battery or a driver has a problem. The DC-versus-AC mix per driver, which is the most expensive habit a fleet can accidentally subsidise. And client or cost-centre allocation, without which a 3PL cannot bill a shipper for the energy its own route consumed. You also lose the ability to argue: “prove this 43 kWh session was not yours” has no answer when every session belongs to one anonymous card.

The protocols themselves warn you off. OCPP 1.6 carries a parentIdTag and OCPI a group_id, described in the spec as an ID that “groups a couple of tokens… so that a session can be started with one token and stopped with another.” The designed answer to “our fleet needs one account” is therefore many tokens grouped under one account, never one token passed between drivers. OCPP even defines a rejection status, ConcurrentTx, for a token that is valid but already in use in another transaction in the same group — so a genuinely shared card can be refused mid-shift, at a charger 40 km from your depot, for reasons the driver cannot see. And because blocking a lost shared card stops every driver at once, lost shared cards tend not to get blocked. An unnamed card outside the depot is an open payment instrument drawn on your account.

Per-Driver Tokens Plus Roaming: The Practical Indian Default

Issue one credential per driver, not per vehicle. Drivers change vehicles far more often than they change employers, and your systems already know who was assigned what on each shift — mapping token to driver to vehicle is exactly what driver management is for, and a credential tied to a person survives a vehicle swap that one tied to a van does not.

The Indian complication is that the public network is app-and-UPI first rather than card first: a driver can discover a charger and pay straight from a bank app, which is superb for coverage and useless for attribution, because a UPI payment identifies a bank account, not a fleet vehicle (we covered that shift in our guide to Unified Bharat eCharge). So the question to put to a CPO is not “do you issue an RFID card for EV charging” but whether they can issue one token per driver on a single fleet account and hand you the session data behind it. Five things to settle before signing:

• Tokens and grouping. One token per driver under one billing account, with group_id or parentIdTag support so the tokens behave as one account without behaving as one identity.
• Session data, not a PDF. Charge detail records by API, including token uid, token type and the authorisation method used — a monthly statement is a bill, not data.
• Revocation speed. How fast can one token be blocked, by whom, and does blocking it disturb anyone else’s charging?
• Offline behaviour. OCPI’s whitelist setting (ALWAYS, ALLOWED, ALLOWED_OFFLINE, NEVER) decides whether your driver charges or is stranded when the site loses connectivity — a live question at Indian highway locations.
• Reach. Which networks the token works on, under which roaming arrangement, and whether those sessions arrive in the same feed as the rest.

Get those five right and tokens, assignments and sessions land in one place — the argument for running charging inside a fleet operating system like YoMobility rather than a spreadsheet beside twelve CPO portals. Turning those feeds into a single consolidated charging invoice is the next job, written up in our unified invoicing walkthrough.

Plug & Charge Is The Direction Of Travel, Not This Year’s Answer

Plug & Charge replaces the card with a certificate held in the vehicle: plug in, and car and charger authenticate each other while billing starts with no driver action. The protocol detail — certificates, contract provisioning, what ISO 15118 specifies — is covered on our sister site’s Plug & Charge (ISO 15118) page.

What matters for a fleet manager is the honest state of play. Every session needs a capable vehicle, a capable charger, a certificate chain and a contract relationship at both ends, simultaneously. An Indian fleet has none of that as a guarantee: your vehicles span three-wheelers, vans and cars of different vintages, and your chargers are whoever is nearest when the state of charge hits 20%. You will carry a fallback credential for years — and a fallback your drivers use daily is not a fallback, it is your actual authorisation system.

There is also a limit worth knowing before it disappoints you. Plug & Charge binds the contract to the vehicle — OCPI has a dedicated EMAID token type for exactly this — so it fixes vehicle attribution permanently and says nothing about people. To know which driver chose a ₹24/kWh fast charger when a ₹12 one sat 2 km away, you still need a per-driver layer on top; Autocharge, the cheaper lookalike that recognises the vehicle’s charging port, has the same blind spot. Build the driver layer now and let Plug & Charge remove the friction later.

The Driver Charging Policy, On One Page

None of this survives contact with a depot unless drivers know the rules. Seven lines are enough:

• One credential per driver. Never a shared card, never a card left in a vehicle.
• The credential follows the person; the vehicle comes from the fleet system, not the card.
• A lost card is reported the same shift — one token is blocked, the account keeps running.
• Never start a session for another driver, another vehicle or another company.
• DC fast charging below 30% state of charge, or when the route genuinely requires it.
• No personal payment at a public charger except in a logged exception; home charging is a separate, documented reimbursement process.
• Finance reviews kWh and cost per kilometre by driver every month — not just the network total.

Frequently Asked Questions

Sources: Open Charge Alliance — Open Charge Point Protocol | OCPI Foundation — Open Charge Point Interface | OCPI 2.2.1 specification (PDF)