Why EV Charging Access Control Is Broken
The UK public charging network has surpassed 120,000 chargers, with Zapmap data recording 121,171 by the end of June 2026 and an 11 per cent year-on-year growth rate. Behind those headline numbers sits a quieter problem that operators at every tier of the market are starting to confront: the authentication layer is a mess. RFID cards get lost, cloned, or simply forgotten. Mobile apps demand a charged phone, a working data connection, and the correct network's software already installed. Neither mechanism tells you anything about the vehicle parked in the bay, and neither can enforce the space against an internal combustion engine vehicle that simply pulled in to park. Plate-based access control, built on a cloud ANPR API, solves all three problems with a single REST call per camera frame and no additional hardware at the charger itself.
This article is a practical build guide. It covers the three main deployment scenarios, walks through the end-to-end data flow, explains whitelist design, ICE-parking detection, CPMS integration via OCPP, and the GDPR case for zero-retention processing. Code samples use Python and the NPR API.
The Three Deployment Scenarios
Fleet Depot Chargers
A logistics or utility fleet depot has a fixed, well-known set of vehicles. Access is a closed problem: only registered fleet plates may charge, and cost allocation needs to map energy consumed back to a specific vehicle. RFID cards work here in theory, but they introduce a human variable. A driver who forgets a card cannot charge; a card handed between drivers corrupts the audit trail. A plate-based system removes the token entirely. The vehicle's registration is the credential, and because fleet vehicles are registered with DVSA, the vehicle data (make, model, and fuel type) can be validated at entry to confirm that the arriving asset is an EV and not a petrol pool car that has wandered into the wrong bay.
Public Car Park Charge Bays
Public charge points in car parks present the opposite problem: a completely open population of drivers who have paid for a session through a separate mechanism (contactless, app, or tariff board) and then need the charger released without further friction. The EU's Alternative Fuels Infrastructure Regulation already requires public and semi-public charging stations to offer ad-hoc sessions without a subscription, which means operators cannot gatekeep purely through account-based RFID. Plate recognition fits neatly here: the session payment creates a dynamic whitelist entry linked to the plate read on entry, and the contactor is released automatically when the plate is confirmed on approach to the bay.
Destination Charging at Retail and Hospitality Sites
Hotels, supermarkets, leisure centres, and retail parks increasingly use EV charging as a footfall driver or guest amenity. The charging is often subsidised or free, access is meant to be convenient, and the operator wants to restrict the bays to genuine customers rather than commuters. A plate-based approach allows a hybrid permit model: the guest quotes their registration at check-in or on a loyalty app, the operator's system adds the plate to the active whitelist, and the charger is released on arrival with no tap, no card, and no app required at the bay itself. Destination chargers account for a significant portion of the UK's non-residential charging estate, spanning on-street, hotel, retail, and leisure locations, so getting the access model right at this tier matters at scale.
How Plate-Based Access Works End-to-End
The data flow is straightforward. An IP camera positioned to cover the entry to a charge bay captures a frame each time motion is detected or on a fixed polling interval. Your application code posts that frame to the recognition endpoint:
POST https://nprapi.com/api/v1/recognise
X-API-Key: your-api-key-here
Content-Type: multipart/form-data
-F "image=@frame.jpg"
-F "vehicle=true"
The response is structured JSON containing the recognised registration string, a confidence integer from 0 to 100, vehicle data (make, model, colour) drawn from DVSA records when vehicle=true is set, and a credits_used field. Your application then checks the returned registration against the active whitelist. If the plate is present and confidence meets your threshold (typically 85 or above for a well-lit bay), a webhook fires to the charge point controller instructing it to release the contactor or lift a bay barrier. The entire round trip, from camera frame to contactor release, runs in well under a second on a standard connection.
Where multiple vehicles may be visible simultaneously, adding multiple=true to the request returns a plates array, each item carrying its own registration, confidence, and ISO 3166-1 alpha-2 country code where identifiable. This is useful in wide-angle depot environments where a single camera covers several adjacent bays.
Whitelist Management
Static Lists for Fleets
Fleet depot whitelists are typically maintained in a database table with columns for registration, vehicle nickname, cost-centre code, and an active flag. A nightly sync from the fleet management system keeps the list current as vehicles rotate in and out of service. Because the ANPR API returns vehicle data including fuel type when vehicle=true is set, you can add a secondary validation step that rejects any plate where the returned fuel type is petrol or diesel, even if the registration is on the whitelist. This guards against the edge case of a fleet plate being transferred to a replacement ICE vehicle before the whitelist is updated.
Dynamic Session-Linked Lists for Public Pay-to-Charge
For public bays, the whitelist entry is ephemeral. When a driver pays for a session at a payment terminal or through an operator app, your backend creates a time-bounded whitelist record tied to the registration they provide. The record expires either when the session ends (detected by the charger's energy meter reporting zero draw) or after a maximum dwell window, whichever comes first. This means the list is always small and accurate: no stale entries, no long-term plate storage, and no data that needs retrospective deletion.
Hybrid Permit Models for Mixed Sites
Destination sites often need both modes running simultaneously. A hotel may have six bays: two permanently open to guests who have registered at check-in (dynamic mode), and four reserved for a fleet client whose vehicles depot overnight (static mode). A simple priority field in the whitelist table handles the overlap. Fleet entries take priority; guest entries fall through to dynamic matching. The same API call serves both, and the application logic routes the response to the appropriate controller.
Handling ICE Parking and Overstay Enforcement
ICE-ing, the practice of a petrol or diesel vehicle occupying an EV charge bay, is a well-documented problem. Private operators typically issue penalty notices in the range of £50 to £100 for unauthorised occupation of charge bays. Despite this, enforcement without automated detection relies on a patrol officer spotting the vehicle, which is impractical at most sites.
An ANPR-based system changes the economics of enforcement. When a vehicle arrives at a charge bay, the API call returns both the registration and, with vehicle=true set, the fuel type as recorded by DVSA. If the fuel type is returned as petrol or diesel and the plate is not on the fleet whitelist, your application can immediately trigger an alert to a site management dashboard, send a notification to an on-site display, or fire a webhook to a parking enforcement platform to begin the penalty charge notice workflow. The entry timestamp logged at the same moment provides the evidence trail. Overstay enforcement follows the same pattern: if the plate has been in the bay for longer than the permitted session window and the charger reports a completed session, a second API call on re-read confirms the vehicle has not moved, and the enforcement webhook fires.
For fleet depots, the vehicle data validation described in the whitelist section provides an equivalent control. The DVSA data returned via the vehicle=true flag reflects the registered specification of the vehicle, so a genuine EV will carry a fuel type indicating battery electric or plug-in hybrid, while a petrol or diesel pool car will be flagged immediately without any manual inspection.
Integrating with CPMS Platforms via OCPP
OCPP (the Open Charge Point Protocol) is the global open communication standard between charging stations and charge point management systems. It enables remote monitoring, authorisation, transaction processing, and smart charging across hardware from any compliant manufacturer. OCPP 2.0.1 was published as IEC standard IEC 63584:2024 in late 2024. OCPP 2.1, released in January 2025 and subsequently published as IEC 63584-210:2025, extends the specification with distributed energy resource control and vehicle-to-grid capabilities. At the application level, the CPMS sends a remote start transaction command to the charger when a session is authorised, and the charger reports energy metering data back through the same connection.
Connecting ANPR-based access to an OCPP CPMS is architecturally clean. Your ANPR middleware receives the API response, checks the whitelist, and on a successful match calls your CPMS's webhook or REST endpoint to issue a RemoteStartTransaction command containing a generated session token. The CPMS then handles the OCPP dialogue with the physical charger. The ANPR system never speaks OCPP directly; it simply acts as the authorisation oracle that feeds the session token. This separation means you can integrate with any OCPP-compliant CPMS without modifying the charger firmware or the management platform, provided the CPMS exposes a webhook or API for remote start commands.
For barrier-controlled bays where no charger contactor is involved, the webhook fires directly to the barrier controller's API instead. The pattern is identical: ANPR response in, authorisation decision out, physical action triggered. The ANPR middleware is stateless beyond the current whitelist lookup, which keeps the integration surface small and easy to test.
Camera Positioning and Image Quality
Cloud ANPR APIs return accurate results when the input image is sharp, well-lit, and correctly angled. Charge bay environments present specific challenges that are worth addressing at installation time rather than in code.
Mount cameras at a height of between 1.2 and 2.0 metres and at an angle of no more than 30 degrees from perpendicular to the plate. Steeper angles distort character geometry and reduce confidence scores. In covered car parks, supplementary IR illumination is worthwhile because overhead lighting is rarely aimed at plate height. For outdoor bays, choose cameras with wide dynamic range sensors to handle the contrast between headlamps at night and direct sunlight in the afternoon. A camera with at least 2 megapixels of resolution ensures that the plate characters occupy enough pixels for reliable recognition even at the outer edge of the capture zone.
Trigger the API call on motion detection rather than on a fixed polling interval. This reduces API credit consumption significantly and means the recognition fires when a vehicle is stationary or nearly so, at the optimal point for character clarity. Where the site has a boom barrier, position the camera so that the vehicle must stop before the barrier, giving a guaranteed stationary target for the recognition call.
GDPR and Data Minimisation
The Information Commissioner's Office is clear that a vehicle registration mark is personal data in the context of an ANPR system, because the purpose of the system means you are likely to be able to identify an individual through further processing. The ICO's guidance on video surveillance states that operators should only keep data for the minimum period necessary and should delete it once it is no longer needed. Retaining plate data for vehicles that are not of interest, for example vehicles that were authorised and departed without incident, is likely to be excessive and non-compliant.
For charge point operators, the correct architecture is zero-retention processing. The ANPR API call is made, the recognition result is used to make an authorisation decision, and neither the image nor the plate string is written to persistent storage for non-flagged vehicles. The only records retained are those directly required for billing (session start, session end, energy consumed, and the registration linked to a paid session) and any enforcement evidence for ICE or overstay incidents. This is data protection by design, the principle that the UK GDPR requires organisations to embed into processing systems from the outset rather than retrofit.
Your Data Protection Impact Assessment for an ANPR charge point deployment should document: the lawful basis for processing (legitimate interests for fleet access control, or contract performance for paid public sessions); the specific retention periods for each category of record; the mechanism by which non-flagged vehicle data is discarded immediately; and the signage plan, because the ICO requires clear and prominent signs informing drivers that ANPR is in use and identifying the data controller. A DPIA is required when ANPR processing is likely to be high risk to the rights and freedoms of individuals, and systematic monitoring of a car park qualifies as such a use case.
A cloud API architecture assists with GDPR compliance in a way that on-camera or embedded edge processing does not. Because the processing happens in your application layer rather than inside a camera appliance with its own storage, you have full programmatic control over what is retained and what is discarded. You can enforce zero-retention by simply not writing the result to a database for non-flagged vehicles. With an embedded camera solution, the camera's own firmware often buffers images and recognition results internally, creating a data store you do not fully control.
Code Walkthrough: Python Integration
The following minimal example shows the full cycle: API call, JSON parsing, whitelist check, and webhook dispatch to a charge point controller. It assumes you have a whitelist stored as a Python set for demonstration purposes, and a charge point controller that accepts a POST webhook to begin a session. Replace CONTROLLER_WEBHOOK with the actual endpoint URL provided by your CPMS.
import requests
API_URL = "https://nprapi.com/api/v1/recognise"
API_KEY = "your-api-key-here"
CONTROLLER_WEBHOOK = "https://your-cpms-host/webhook/start-session" # replace with your CPMS endpoint
WHITELIST = {"AB12CDE", "XY34FGH", "LM56NOP"}
MIN_CONFIDENCE = 85
def recognise_and_authorise(image_path: str) -> dict:
with open(image_path, "rb") as f:
response = requests.post(
API_URL,
headers={"X-API-Key": API_KEY},
files={"image": f},
data={"vehicle": "true"},
)
response.raise_for_status()
data = response.json()
if not data.get("success"):
return {"authorised": False, "reason": "recognition_failed"}
registration = data["registration"]
confidence = data["confidence"]
vehicle = data.get("vehicle", {})
fuel_type = vehicle.get("fuelType", "").lower()
if confidence < MIN_CONFIDENCE:
return {"authorised": False, "reason": "low_confidence",
"registration": registration, "confidence": confidence}
if registration not in WHITELIST:
return {"authorised": False, "reason": "not_on_whitelist",
"registration": registration}
if fuel_type in ("petrol", "diesel"):
return {"authorised": False, "reason": "ice_vehicle_detected",
"registration": registration, "fuel_type": fuel_type}
webhook_payload = {
"registration": registration,
"action": "start_session",
"bay_id": "BAY_01",
}
webhook_response = requests.post(CONTROLLER_WEBHOOK, json=webhook_payload)
webhook_response.raise_for_status()
return {"authorised": True, "registration": registration,
"confidence": confidence, "credits_used": data["credits_used"]}
if __name__ == "__main__":
result = recognise_and_authorise("bay_frame.jpg")
print(result)
This is deliberately minimal. In production you would replace the set-based whitelist with a database lookup, add structured logging without persisting the registration for non-flagged vehicles, handle the multiple=true flag for multi-bay cameras, and wrap the CPMS webhook call in a retry loop with exponential backoff. The confidence threshold of 85 is a reasonable starting point; tune it upward in high-traffic sites where false positives are costly, or slightly downward in low-light environments where you have validated the camera output against your accuracy requirements.
Why a Cloud API Beats On-Camera Solutions
On-camera ANPR solutions embed the recognition model in the camera's own processor. The immediate appeal is low latency and no cloud dependency, but the architectural trade-offs are significant. Model updates require firmware access to every camera on site. Recognition accuracy is fixed at the model version shipped with the hardware. Multi-site normalisation, where you want consistent behaviour and a single whitelist across several locations, requires a proprietary management layer that locks you to a single hardware vendor. As discussed above, the camera's internal storage also complicates GDPR compliance.
A cloud API externalises the recognition model entirely. You send an image and receive JSON. Model improvements are deployed by the API provider without any action on your part. Your application logic, whitelist, webhook targets, and retention policy all live in code you control and can audit. The marginal cost per recognition call is predictable and scales with usage rather than requiring upfront capital expenditure on specialised hardware. For most charge bay deployments, the camera is simply a standard IP camera costing a fraction of a smart ANPR appliance, and the intelligence lives in your application layer where it belongs.
Getting Started
Plate-based access control is not a novel concept, but the convergence of affordable IP cameras, reliable cloud recognition APIs, and OCPP-standardised charge point management means it is now the lowest-friction, lowest-hardware-cost path to smart access control at EV charge bays. A single REST call per camera frame replaces RFID readers, card management workflows, app onboarding funnels, and manual enforcement patrols. The same call that authorises a session can detect an ICE vehicle and trigger an enforcement workflow, or confirm a fleet vehicle's fuel type before releasing a contactor.
To get started, sign up for the NPR API at nprapi.com and run the Python example above against your own test images. The full API reference, including batch processing via POST https://nprapi.com/api/v1/batch and status polling via GET https://nprapi.com/api/v1/batch/{uuid}, is available at nprapi.com/docs. Once you have a working recognition loop, the charge point integration reduces to a webhook call, and you have the core of a production access control system.