Technical library / Fleet Operations

Fleet RFID Charging Cards: A Guide for Commercial EV Operations

How fleet RFID charging cards support vehicle allocation, OCPP integration, tax-relevant records, multi-depot authorization, and driver issuance.

Article details

Published
May 2, 2026
Updated
July 10, 2026
Reading time
8 min read
Publisher
ChargeRFID
Back to Resources

By ChargeRFID

Review method: We checked this guide against the primary regulatory, protocol, and manufacturer references listed below. Product recommendations reflect ChargeRFID's manufacturing perspective and should be validated with your reader, charger, and backend.

Fleet RFID Charging Cards: A Guide for Commercial EV Operations

Running a commercial fleet on electric vehicles changes the economics of charging. Instead of one driver swiping a personal credit card at a forecourt, you have 50, 500, or 5,000 drivers charging across depots, public stations, and home chargers — each session generating cost, kWh, and tax-relevant data that has to land cleanly in fleet management software. Fleet RFID charging cards are how that data gets captured at the source.

This guide covers what makes a fleet RFID charging card different from a consumer card, how the authentication and reporting chain works, and what to specify when issuing cards across a commercial EV program.

What Makes a Fleet RFID Charging Card Different

A charging card presents a token. Whether that token represents a driver, vehicle, depot, cost centre, or contract is determined by the fleet and charging backends. One card does not inherently identify all of those entities at once.

The card may use AES-authenticated 13.56 MHz credential or another reader-compatible technology. The important distinction is how its identifier or protected application is provisioned and mapped in the backends:

Per-vehicle kWh tracking: — the card's UID is mapped to a specific vehicle in the fleet management system, so every charging session can be allocated to a vehicle.
Driver attribution: — paired with vehicle telematics, the card lets the fleet attribute energy spend to the driver assigned to that vehicle on that day.
Depot authorization: — backend groups can restrict tokens by depot; cryptographic keys can add another layer only where the cards and readers use a protected application.
Tax-relevant records: — UK treatment depends on vehicle ownership, charging location, business or private use, and how reimbursement is calculated. Session records support the calculation but do not make it programme-specific by themselves.

How Fleet RFID Authentication Works on OCPP Stations

The authorization and transaction flow depends on the OCPP version. A typical OCPP 1.6 path looks like this:

When a driver taps a fleet card at a depot or public station:

1.The station extracts the UID and sends `Authorize.req` to the Central System.
2.The Central System checks the UID against the fleet's allow list (often filtered by depot, driver group, or vehicle group).
3.On approval, the station sends `StartTransaction` with fields including the connector, idTag, timestamp, and meter start value.
4.At session end, `StopTransaction` sends the transaction identifier, timestamp, meter stop value, and optional transaction data. Duration, energy, and a billing CDR are calculated or assembled by downstream systems; they are not a CDR embedded in the OCPP 1.6 message.
5.The charging management system can enrich the session and send records to the fleet's reporting backend. OCPP 2.x uses the different `TransactionEvent` model rather than the OCPP 1.6 start/stop message pair.

For fleets running mixed depot + public charging, OCPI roaming feeds CDRs from external CPOs back through the fleet's MSP into the same reporting pipeline.

Per-Vehicle vs Per-Driver Card Models

Most fleets choose between two architectures:

Per-vehicle cards sit with the vehicle (in the glovebox or attached to a key fob). Pros: simple driver experience, easy reassignment when drivers swap. Cons: stolen with the vehicle, can't isolate driver behavior.

Per-driver cards travel with the driver across vehicles. Pros: direct driver-level attribution. Cons: accurate vehicle and mileage allocation still requires assignment or telematics data, and tax treatment must follow the applicable HMRC rules rather than the card model alone.

Many large fleets issue both — a per-driver card for cost allocation, a per-vehicle key fob for redundancy and ease of access.

Multi-Depot Key Management

For fleets running multiple depots, authorization can be enforced in the backend by token group, vehicle, driver, or site. AES-authenticated 13.56 MHz credential also supports diversified application keys when the deployed readers authenticate a protected application rather than reading only the public UID.

With a correctly designed protected application, separate key domains can limit the scope of a key compromise. Rotating those keys still requires a documented reader, card, secure-module, and backend process; a public-UID authorization scheme instead revokes individual or grouped tokens in the backend.

Avoid one shared application key across an entire fleet, but do not add card keys that the charging readers and backend never authenticate. Match the control to the actual authorization architecture.

Reporting: From OCPP CDR to HMRC-Ready Output

The card is just the entry point. The reporting chain is what makes a fleet program work financially.

A typical UK fleet workflow:

1.Driver taps card → station authorizes → session runs → CDR recorded.
2.CDR is enriched with driver, vehicle, and depot metadata from the fleet management system.
3.Energy cost is calculated using the contracted tariff (often time-of-use or pass-through).
4.Mileage and charging-location data are combined where needed to apply the relevant HMRC reimbursement or benefit treatment.
5.Reviewed output can then support payroll, expense, or tax workflows appropriate to the vehicle ownership and use case.

The card-to-report chain should be auditable end to end. That audit trail normally comes from station meter values, OCPP events, CPO/eMSP session and CDR records, tariff data, token mappings, and fleet metadata. AES-authenticated 13.56 MHz credential transaction-MAC features do not automatically create or validate the backend charging CDR, especially when a charger reads only the card UID.

Roaming for Mixed Depot + Public Charging

Most commercial fleets can't operate on depot-only charging. Long-haul drivers, last-mile operators with route variance, and any fleet with home-charging policies all need public network access via the same card.

This is where token publication and active roaming agreements matter. A fleet card issued by an eMSP can work at contracted CPOs reached through a hub or direct OCPI/OICP connection. Coverage should be taken from the eMSP's current contractual network list; a platform's total connected-point count is not a guarantee that a particular card is accepted everywhere.

The CDRs come back to the fleet's MSP, get re-priced if the contract uses a markup model, and flow into the same reporting pipeline as depot sessions.

What to Specify When Issuing Fleet RFID Charging Cards

An example procurement checklist is:

Chip and application: reader-compatible technology; use AES-authenticated 13.56 MHz credential keys only where the reader authenticates the protected application
Material: recycled PVC (most common) or FSC wooden for ESG-led programs
Form factor: ISO 7810 ID-1 cards plus key fobs for vehicle attachment
Print: full-color with vehicle/driver ID, fleet logo, anti-tamper laser engraving
Encoding: pre-encoded UID, idTag aligned with MSP format, depot-specific diversified key
Roaming: token publishing and active eMSP–CPO agreements for the required networks
Reissue policy: loss, revocation, replacement, and synchronization workflow based on pilot data
Commercials: current MOQ, price, lead time, and replacement terms in a written supplier quote

Common Mistakes in Fleet Card Programs

Issuing cards before the MSP integration is live: — drivers tap and get rejected because the idTag isn't registered yet.
One shared application key across the fleet: — creates unnecessary compromise scope when protected applications are actually in use.
No reissue process: — leaves lost cards, replacement tokens, and backend synchronization unmanaged.
Public-charging blind spots: — assuming "we'll just install more depot chargers" instead of designing roaming in from day one.
Mismatched UID format: — different MSPs expect different idTag formats (4-byte, 7-byte, hex vs decimal); get this aligned before encoding 5,000 cards.

Where to Go From Here

A fleet RFID charging card program is a four-axis spec: chip security, encoding format, roaming reach, and reporting integration. Get those right and the cards become invisible infrastructure — drivers tap, energy flows, data lands cleanly in the fleet's books.

Browse our recycled PVC and FSC wooden EV charging cards or read how we built fleet card programs with a selected EV charging programme and a selected fleet charging programme. Talk to us about your fleet's charging program — we'll help you spec the right card and align it with your MSP.

Company, network and product names referenced in this article are the trademarks of their respective owners. They are used descriptively to identify systems our cards interoperate with. ChargeRFID is an independent manufacturer and this article does not assert any affiliation, partnership or endorsement.

Primary sources

Official references used to review the regulatory, protocol, and chip-level claims in this guide.

Share:

Next step

Turn the research into a card specification.

Share the reader, chip, data or rollout context and we will identify the decisions required for samples and production.

Fleet RFID Charging Cards: A Guide for Commercial EV Operations | ChargeRFID