A card does not create roaming
Network access exists only after commercial connection and token distribution or authorization are in place.
Roaming credential programme
Network Roaming
Physical RFID credentials for roaming programmes where token records, identifier formats and lifecycle status stay consistent across eMSP, CPO and hub systems.
Programme outcome
A physical credential whose token record, identifier format and lifecycle state stay consistent across participating systems.
Review recommended productDesigned for
eMSPs, CPOs and mobility platforms operating bilateral or hub-based roaming
01
Roaming layer
OCPI 2.2.1 / 2.3.0, OICP or eMIP
02
Station layer
Reader + OCPP + CPO backend
03
Identity
Issuer-controlled token record
04
Commercial scope
Contracts and entitlement sit outside the card
Operating model / 01
Follow the credential across the complete authorization chain.
The physical card is one controlled input. Reader behaviour, platform records and operating rules determine whether the correct account is authorized and traced.
A physical credential whose token record, identifier format and lifecycle state stay consistent across participating systems.
- 01
eMSP-issued credential
The mobility provider assigns a physical card or keyfob to a customer and controls its lifecycle status.
- 02
Visited charging station
The station reads the credential and forwards the identifier to the CPO backend using its supported authorization flow.
- 03
CPO authorization layer
The CPO checks a local token store or requests authorization through its roaming connection.
- 04
Bilateral link or roaming hub
OCPI, OICP or eMIP carries token, authorization and related session information between contracted parties.
- 05
Session and CDR return
Session and charge-detail data travel back through the commercial chain; the card is only the identity trigger.
Specification matrix / 02
Decisions to close before production.
A production-ready brief states what must be decided, how it will be implemented and what evidence will count as acceptance.
DecisionWhat to defineAcceptance evidence
01
Roaming topology
What to define
Identify bilateral partners, hub connections, environments and protocol versions.
Acceptance evidence
Every target route has an owner and test endpoint.
02
Token ownership
What to define
Define issuer, party/country identifiers, token type, contract reference and lifecycle authority.
Acceptance evidence
The token remains globally unique within the agreed ecosystem.
03
UID normalization
What to define
Agree hexadecimal or decimal representation, byte order, padding, case and permitted length.
Acceptance evidence
Reader output, CSMS record and roaming payload resolve to the same value.
04
Authorization mode
What to define
Document whitelist push, real-time request, cache and offline behaviour for each target CPO estate.
Acceptance evidence
Accepted, blocked, expired and unknown states produce the expected result.
05
Status propagation
What to define
Define how newly issued, blocked, expired and replaced tokens move between parties.
Acceptance evidence
A status change reaches the test CPO within the agreed operating window.
06
Session reconciliation
What to define
Specify references used to reconcile authorization, session and CDR records.
Acceptance evidence
Pilot sessions return to the correct eMSP customer record without orphan data.
07
Exception handling
What to define
Assign ownership for rejected tokens, reader mismatches, partner outages and disputed sessions.
Acceptance evidence
Support can trace a failure across station, CPO, hub and eMSP logs.
Failure controls / 03
Design out the common failure points.
Most failed launches are not caused by print quality. They come from unclear identifiers, untested readers, incomplete data ownership or weak lifecycle control.
Normalize identifiers once
Byte order, padding and case mismatches are common causes of failed authorization; lock the representation before production.
Test lifecycle states
A successful first tap is insufficient. Validate block, expiry, replacement and reactivation paths across the same route.
Keep settlement out of card claims
CDR exchange, tariffs and settlement belong to roaming platforms and contracts, not to credential manufacturing.
Delivery path / 04
Move from brief to controlled operation.
Each phase should close with evidence that can be reviewed by operations, platform and procurement teams.
- 01
Topology map
Document issuer, partners, hubs, protocol versions, token ownership and support contacts.
EvidenceRoaming responsibility matrix
- 02
Identifier pilot
Produce a small set with known values and compare reader, CSMS and roaming representations.
EvidenceEnd-to-end token trace
- 03
State testing
Exercise accepted, unknown, blocked, expired, offline and replacement scenarios.
EvidenceAuthorization result matrix
- 04
Market launch
Release only the markets and partner routes that have completed acceptance.
EvidenceApproved market/partner register
- 05
Change control
Manage new partners, protocol upgrades and replacements without changing the physical identity rules silently.
EvidenceVersioned interoperability record
Responsibility boundary / 05
Separate manufacturing from platform operation.
A precise boundary prevents the card from being blamed for configuration, entitlement or settlement decisions that live elsewhere.
ChargeRFID / manufacturer
Controls the approved material, chip, antenna, artwork, encoding, variable data, batch QC and production record.
CPO, eMSP or CSMS team
Defines accepted identifier format, reader behaviour, token import, authorization states, security application and technical acceptance.
Programme owner
Owns assignment, activation, contracts, access policy, tariffs, customer support, replacement approval and end-of-life decisions.
Credential options / 06
Physical formats to evaluate after the system brief is clear.
OCPP Workflows / idTag / idToken / UID Formatting
RFID Cards for OCPP Charging Networks
RFID credentials prepared for the identifier and authorization workflow used between EV charger readers and OCPP charging-management systems.
Review recommended product
Fleet Operations / Bulk Token Data / Replenishment
EV Fleet Charging Cards
Branded RFID fleet charging credentials with unique token data, driver or vehicle numbering, bulk platform import and controlled replenishment.
Review recommended product
Recycled PVC / Custom RFID / UID Mapping
Recycled PVC EV Charging Cards
Custom RFID charging cards with a recycled-PVC card body, reader-matched chip options, programme artwork and UID-to-account data handoff.
Review recommended productTechnical library / 07
Continue the implementation research.
These sources define the surrounding technology and operating interfaces. ChargeRFID manufactures physical credentials; platform configuration, roaming contracts and charging-station certification remain with the relevant operators and vendors.
EV Infrastructure / 6 min read
RFID Roaming: How One Card Works Across Participating EV Charging Networks (2026 Guide)
One RFID card, every charging network. How EV roaming works through OCPI and OICP, why drivers stop juggling an app per network, and how fleets get one card and one invoice across 1M+ chargers in 2026.
Read More
Selected work / 2 min read
Octopus Electroverse — EV charging card archive
Octopus Electroverse: a quiet production record of a custom-printed PVC EV charging card.
Read MorePrimary implementation references
Programme questions / 08
Questions procurement and technical teams usually resolve.
01Will a newly manufactured card automatically work on roaming networks?
No. The credential identifier must be registered and authorized through the eMSP/CPO commercial and technical connection. Manufacturing produces the physical credential; it does not create a roaming contract or token entitlement.
02What is the difference between OCPP and OCPI?
OCPP is primarily the station-to-management-system protocol. OCPI connects CPOs and eMSPs for roaming data such as locations, tokens, sessions, tariffs and CDRs. OICP and eMIP provide alternative roaming interfaces.
03Which OCPI version should the card support?
The card does not implement OCPI. The participating platforms agree the OCPI version, while the physical credential and identifier must match the reader and token rules used by those platforms.
04Can one identifier be represented differently by different systems?
Yes, and that is a common failure source. Hex/decimal conversion, byte order, padding, leading zeros and case should be fixed in the interface brief and verified end to end.
Other operating programmes
Fleet Authentication
RFID credentials for depot, workplace and public charging, with controlled driver or vehicle assignment, platform-ready identifiers and replacement records.
CPO & eMSP Credential Programmes
White-label cards and keyfobs prepared around your brand, identifier format, platform import, launch volume and repeat-order workflow.
Site & Member Access
Credential programmes for workplaces, depots, residential sites and destinations that need controlled access by employee, resident, visitor or account.
Secure RFID Migration
A controlled route from legacy or UID-only credentials to reader-matched card technology with a practical pilot, data plan and phased reissue.
Automotive & Premium Membership
Branded credentials for vehicle delivery, dealership charging, loyalty and premium member programmes—with controlled serialization and presentation.
Turn rfid cards for ocpp charging networks into a controlled programme specification.
Share the reader estate, identifier rules, security requirement, platform handoff, volume and rollout markets. We will return the questions needed for samples and production approval.