Building an EV Charging Station with RFID Authentication: What We Learned

Every six weeks or so, a founder messages us about building an EV charging network. Same set of questions every time: Should we use RFID cards, app-based authentication, or both? How do chargers actually talk to our backend? Why does every quote we get from hardware vendors look so different? This post is the version of that conversation we've ended up writing out so often we figured we'd just publish it. Honest, opinionated, with real INR numbers from production deployments we've worked on.

The whole architecture in one diagram (in words)

Before we get into RFID specifically, here's the stack any serious EV charging network looks like in 2026. Skip this section only if you've already built one.

• Charge point hardware — the physical AC or DC charger with at least one RFID reader, an LCD screen, and a network module (4G or Ethernet)
• OCPP 1.6-J or 2.0.1 — the open-source protocol over WebSocket the charger uses to talk to your backend. This is the standard. If your hardware doesn't speak OCPP, walk away.
• Central System (CSMS) — your backend. Receives connection from every charger, handles authentication, billing, session lifecycle, telemetry. Usually a Node.js or Laravel WebSocket server.
• RFID database — a table of issued cards with their UIDs, the user they're linked to, balance or plan, and validity dates
• Mobile app — for users to top up balance, see session history, find chargers, optionally start charging via NFC or QR
• Admin portal — for your operations team to provision chargers, issue cards, set tariffs, monitor uptime, refund users
• Payment gateway — Razorpay or PhonePe for India, plus optional B2B invoicing for fleet customers

RFID is one piece of this. It is a really important piece, because it's how 70-80% of your real-world charging starts get authenticated. The remaining percentage starts via the app or via QR codes scanned from the charger screen.

Why RFID still wins in 2026 (despite app-only being trendier)

Founders frequently ask why we don't just go app-only. Here's the honest answer:

• RFID works when the user has poor signal. EV chargers live in basement parking, highway rest stops, and concrete-walled commercial garages. Phones don't always connect; cards always do (assuming the charger itself has connectivity).
• RFID works when the user's phone battery is dead — you'd be surprised how often this happens at a charger.
• RFID is faster — tap-and-go beats unlock-phone-open-app-find-charger-tap-start by 40 seconds on average. At public chargers with queues, this matters.
• RFID is cheaper for fleet customers. A small logistics company doesn't want to install your app on 200 driver phones. They want 200 cards in a drawer.
• Fallback is non-negotiable. When the app, the API gateway, or the user's data plan fails, RFID is the offline-friendly backup.

Our default architecture: support both RFID and app-based auth on every charger, and let the user pick whatever works at that moment. Adding RFID hardware adds maybe ₹3-5k to the BOM cost of a charger; building the backend support for it is roughly two weeks of engineering. Skipping it to save that cost is a false economy.

Card-based RFID vs phone NFC — which to issue

This catches a lot of new operators by surprise. There are two completely different RFID use-cases:

Physical RFID cards (what most operators issue)

• Standard: ISO/IEC 14443 Type A, MIFARE Classic 1K is most common in India
• Cost: ₹15-40 per card in bulk, ₹80-150 with custom branding
• Issuance: hand them out at the time the user registers, mail them, or sell at retail counters
• Lifespan: 5-7 years if the user doesn't physically destroy it
• Security: MIFARE Classic is technically broken (cloneable with a Proxmark) but in practice you're authenticating by UID against your own database, so cloning a UID just means the cloner can charge from someone else's account — easy to detect via velocity/anomaly checks

Phone NFC (HCE — Host Card Emulation)

• User taps their unlocked Android phone (or iPhone with the right Apple Pay-style API hack) on the charger reader
• Phone runs your app in HCE mode and emits an RFID-compatible UID derived from the user's account
• Cost: free per user (no card needed)
• Lifespan: as long as the user has the app installed
• Friction: user must have phone unlocked, app installed, NFC enabled — surprisingly often not the case

Our practical recommendation: issue physical cards by default to all customers, and offer NFC HCE as an opt-in inside the app for power users. Don't try to make NFC the only path until you have 5,000+ active users with smooth UX — the support tickets in the first year will eat you.

What actually happens when someone taps a card

Walking through one transaction end-to-end so the rest of the architecture makes sense:

1. User taps their card on the charger's RFID reader. Reader emits the UID over a serial bus to the charger's main controller.
2. Charger sends an OCPP `Authorize` request over its open WebSocket to your CSMS, with the card UID as the `idTag` parameter.
3. Your backend looks up the UID in the RFID table. If the user has positive balance and an active plan, the backend responds `Accepted`. Otherwise `Blocked`, `Expired`, `Invalid`, or `ConcurrentTx` (already in another active session).
4. Charger displays the result on its screen. On `Accepted`, charger waits for the user to plug in the connector.
5. When the connector is plugged and locked, charger sends `StartTransaction` with the card UID, meter reading, and timestamp. Backend creates a session record, returns a transactionId.
6. Charger streams `MeterValues` every 30 seconds (configurable) so the backend can calculate live cost and update the user's app.
7. When the user unplugs, charger sends `StopTransaction` with the final meter reading. Backend calculates total energy, cost, debits the user's balance, sends an SMS/push notification with the receipt.

The whole flow is OCPP standardized — every certified charger speaks the same protocol. This is what makes the EV charging space genuinely buildable; you're not stuck with vendor lock-in like you would be with proprietary APIs.

Hardware that actually works (with what we've shipped)

RFID readers don't all work the same. Things we've learned the hard way:

• Stick to chargers with built-in RFID readers — Delta, ABB, Exicom, Tata Power EZ, Statiq, and Numocity all ship hardware that integrates RFID natively into the OCPP flow. You don't want to retrofit a USB reader to a charger that wasn't designed for it.
• 13.56 MHz HF readers (MIFARE compatible) cover 99% of card-based use cases. Don't get pulled into LF (125 kHz) options — those don't support newer secure cards and are slowly being phased out.
• Read range of 3-5 cm is correct. If a vendor claims 'long-range RFID for EV charging' at 30 cm, they're either using UHF (overkill, expensive, regulated) or lying about the range.
• Always specify ISO 14443 Type A AND Type B support — Indian government cards (some metro and bus passes) are Type B. You want to support both for cross-utility scenarios down the line.
• Get hardware that supports OCPP 2.0.1 even if you only deploy 1.6-J today. The migration is non-trivial later if your fleet doesn't support 2.0.1 firmware.

Cost breakdown for a 10-charger pilot network

Real numbers from a deployment we worked on for a small commercial property in Gurugram in 2025. Adjusted for current 2026 prices:

Capex (one-time)

• 10 × 7.4 kW AC charge points with RFID readers: ₹4.5L (₹45k each, mid-range Indian-made hardware)
• Site work — electrical capacity, mounting, signage, paint: ₹2L
• RFID cards (5,000 units, branded): ₹1.25L
• OCPP backend development and admin portal: ₹6-8L (or ₹0 if you license existing — we recommend building if you're going past 50 chargers)
• Mobile app (iOS + Android) — basic version: ₹3-5L
• Total typical capex: ₹17-21L for a 10-charger pilot with full software

Opex (monthly)

• Server/hosting (managed Node.js + Postgres on Railway or AWS): ₹8-12k/month
• Cellular data SIM per charger: ₹150-300/month each → ₹1,500-3,000 for 10
• Payment gateway fees: roughly 2% of revenue passed through
• Maintenance + customer support: 1 part-time engineer ₹40-60k/month for 10-50 chargers

Common production pitfalls we've watched operators hit

• Hard-coding the charger's CSMS URL in firmware. Then you can't migrate hosting. Always make the URL configurable via OCPP or a vendor portal.
• Trusting the charger's clock for transaction timestamps. Charger clocks drift. Always use server-received timestamps for billing.
• Not handling `ConcurrentTx`. A user taps their card a second time mid-session by accident; if you don't reject this with a clear screen message, sessions get tangled and refunds become messy.
• Underestimating offline tolerance. Chargers will lose connection. Cache the last-known authorized list on the charger so it can authenticate offline for a configurable number of minutes, syncing when back online.
• Forgetting RFID UID format normalization. Different readers emit UIDs in different byte orders (LSB vs MSB). Normalize on the way in or you'll have ghost cards that 'work sometimes.'
• Not throttling MeterValues frequency. Every 5 seconds × 10 chargers × 30 days × OCPP overhead = your bandwidth bill is bigger than your electricity bill. 30-60 seconds is fine for billing accuracy.

Where we usually come in

Most operators we work with already have hardware ordered and a vague idea of what the software needs to do. The two places we add the most value are: building the OCPP CSMS that actually scales past 100 chargers without falling over, and the admin portal that lets operations teams provision new chargers, issue RFID cards in bulk, and triage incidents in production.

If you're earlier than that — still picking hardware, still deciding whether to license a CSMS or build one — we'll have an honest conversation about which path makes sense for your specific scale and timeline. For under 20 chargers we usually recommend licensing. For 50+ and any plan to onboard third-party chargers, building your own is genuinely the right call.