Why Reactive Debt Recovery Is No Longer Enough
The traditional forecourt security model works like this: a vehicle drives off without paying, staff note the plate from CCTV, a debt-recovery letter goes out days later, and the operator absorbs the loss while waiting to see whether repayment arrives. That model is breaking under the weight of its own inefficiency. Industry data shows around 178 fuel theft incidents occur at UK forecourts every single day, covering both deliberate drive-offs and no-means-of-payment cases. The average number of weekly drive-offs per petrol station climbed from 2.1 in March 2025 to 3.4 in March 2026, a 62 per cent rise year on year, with the average value per incident rising from £56 to £67. According to Forecourt Trader, an average of 86 per cent of drive-off cases are closed without a suspect being identified, meaning debt-recovery letters are chasing a ghost the majority of the time.
The industry's response in 2026 is moving in a fundamentally different direction: stop the theft before the nozzle is lifted. This guide covers how to build that architecture end to end, using a plate recognition API as the gate between a vehicle arriving at the canopy and the pump being authorised to dispense fuel.
Pump-Gate ANPR vs Entry and Exit Enforcement ANPR
Entry and exit enforcement ANPR is primarily an evidence-gathering and billing tool. The camera reads a plate on the way in and on the way out, calculates dwell time, and either charges a parking fee or flags an overstay. The plate event is processed after the fact. Pump-gate ANPR is architecturally different because it sits in the critical path of a real-time transaction. The recognition result must arrive at the forecourt controller before a pump authorisation signal is sent, which means latency, reliability and decision speed all carry operational weight. A slow response does not mean a failed parking charge; it means a customer waiting at a pump, or worse, a pump that defaults open because the decision window expired.
This distinction has three practical consequences for developers. First, you need a recognition API with a predictable, low-latency response rather than a batch pipeline. Second, your decision logic must handle a confidence threshold and a timeout gracefully, not just a binary match or no-match. Third, the integration must write a pump-hold signal to the forecourt controller immediately on vehicle detection, then release or deny based on the API result, rather than authorising first and checking second.
Camera Placement on the Forecourt Canopy
The canopy is the optimal capture point because every vehicle entering the pump area must pass beneath it and will slow to a near stop to park at a dispenser. That low speed gives the camera more time per plate than a road-speed installation, which relaxes some of the shutter-speed demands.
Mount the capture camera at the canopy edge, positioned to read the front plate of an approaching vehicle. A height of roughly 3 to 4 metres at the canopy fascia, angled downward toward the entry lane at no more than 30 degrees from horizontal, keeps the plate geometry close to flat and avoids the distortion that makes character recognition harder. Keep the horizontal angle below 30 degrees from the vehicle's direction of travel wherever possible. Exceeding that introduces lateral keystoning that degrades recognition accuracy, particularly on shorter plates or those with narrow character spacing.
For focal length, a moderate telephoto, typically 8 to 12 mm on a standard 1/2.8-inch sensor, allows the plate to fill enough of the frame from canopy distance without requiring the camera to be mounted so far back that the image becomes sensitive to vibration or atmospheric shimmer. Aim for a plate width of at least 120 pixels in the captured image. ANPR cameras require infrared illumination to operate reliably at night and in the low-angle winter sun that renders number plates near-invisible to colour cameras. The IR lamp should be synchronised with the camera shutter to deliver a concentrated burst of illumination across the plate. Avoid positioning the camera directly into oncoming headlights; a slight offset so the lens axis does not align with the light source reduces saturation and flare.
Where a site has multiple entry lanes, deploy one capture camera per lane. Do not attempt to cover two lanes with a single wide-angle camera. A wide field of view means the plate is too small in the frame at any useful depth, and the recognition rate falls sharply.
The API Call: Sending a Canopy Frame to NPR API
Once the camera detects a vehicle entering the capture zone, your edge application or middleware captures a still frame and dispatches it to the recognition endpoint. A basic call to NPR API looks like this:
curl -X POST https://nprapi.com/api/v1/recognise \
-H "X-API-Key: your-api-key-here" \
-F "image=@canopy_frame.jpg" \
-F "vehicle=true"
The image field accepts a JPEG or PNG sent as a multipart file upload. Setting vehicle=true instructs the API to attach DVSA vehicle data to the response, returning make, model and colour alongside the plate string. This is useful for cross-referencing against a known offender record where the plate has been cloned, because a watchlist entry for a blue Ford Transit will not match a confirmed red Volkswagen Golf carrying the same registration, reducing the risk of a false block on an innocent motorist.
The JSON response in single-plate mode contains the fields you need to drive authorisation logic:
{"success": true, "registration": "AB12CDE", "confidence": 94, "credits_used": 1}
The confidence field is an integer from 0 to 100. It represents how certain the recognition engine is that the returned plate string is accurate. This is not a quality score for the image; it is a character-level confidence aggregate. Where a site has multiple pumps and vehicles often park at an angle that partly obscures the plate, you can pass the multiple=true flag to receive a plates array, where each element contains a registration, confidence and country code. This allows you to handle forecourts with high vehicle density or unusual parking patterns.
Decision Logic: Authorise, Block, or Alert
The recognition result feeds a decision tree that your middleware executes before issuing a signal to the forecourt controller. A clean implementation handles four states.
Whitelist pass-through. If the returned registration matches an entry in your whitelist, typically fleet accounts, staff vehicles or known regular customers with pre-authorised accounts, issue an authorise signal immediately without staff intervention.
Blacklist block. If the plate matches your blacklist, send a deny signal to the controller, hold the pump and push a visual and audio alert to the till screen. Staff should be trained to request pre-payment rather than confronting the driver, reducing the risk of aggression incidents.
Unknown plate, confidence above threshold. For plates not on either list but read with confidence above your chosen threshold, typically 85 or above, allow the pump to enter a normal authorisation flow. Log the plate, timestamp and pump number against the transaction for NMOP recovery purposes if payment is later declined.
Low confidence or no read. If the API returns a confidence below threshold, or if the recognition call fails or times out, your system must apply a fallback policy. Fail-secure means the pump stays locked and staff authorise manually. Fail-open means the pump proceeds normally. Most operators in 2026 choose fail-open for the canopy camera because denying fuel to every vehicle with a dirty or partially obscured plate would cause unacceptable queue disruption. Reserve fail-secure for explicit blacklist checks, where the cost of a missed block outweighs the disruption of a wrongful one.
Integrating with the Forecourt Controller
The forecourt controller is the hardware and software layer that sits between the EPOS and the physical pump dispensers. Manufacturers including Tokheim, Gilbarco Veeder-Root and Wayne all produce controllers that expose interfaces for authorising, holding and denying individual pump heads. Forecourt controllers typically communicate with in-store systems via TCP/IP on the site LAN, while the connection to the pump dispensers themselves often uses legacy serial interfaces such as RS-232, RS-485 or current-loop protocols specific to each dispenser manufacturer. As newer dispenser hardware is deployed, many of those serial connections are being replaced by TCP/IP links, simplifying integration.
For pump-gate ANPR, your middleware sits between the ANPR decision engine and the forecourt controller's command interface. The practical flow is: camera triggers on vehicle arrival; middleware calls NPR API and receives a result within the authorisation window, typically under two seconds; middleware translates the decision into a pump-hold or pump-authorise command and sends it to the controller. Most controllers expose a network socket on the site LAN that accepts commands in either a proprietary ASCII protocol or, increasingly, an IFSF-compliant message format. Wayne DART protocol pumps use a serial command structure that you will need to bridge through a serial-to-TCP converter if your middleware is purely IP-based.
On older sites where direct controller API access is not available, a middleware shim that listens on the same network segment and injects authorisation messages can achieve the same result, though this approach carries integration risk and should be validated in a test environment with the controller manufacturer's support before going live.
EPOS Tie-In: Linking Plate Events to Transaction Records
The EPOS link serves two purposes: it associates a recognised plate with a specific transaction record for audit and debt recovery, and it provides the till screen alert that prompts staff to act. When the ANPR middleware identifies a vehicle at a pump, it writes the registration, confidence score, vehicle data and pump number to a shared transaction context. When the EPOS closes the transaction, whether by card payment, cash or a declined payment, it records that plate against the receipt.
For EPOS systems that do not natively accept plate event data, a generic OPT (outside payment terminal) protocol integration or a simple TCP message to the POS can push a plate annotation into the transaction log. The key requirement is that the plate event and the transaction share a common identifier, the pump number and the timestamp window, so that a post-fill query can retrieve the plate associated with any given sale without ambiguity.
Watchlist and Blacklist Management Across Multi-Site Networks
A blacklist that lives only on one site defeats much of its own purpose. Repeat offenders routinely target multiple forecourts across a region; industry data indicates that in April 2025, 47 per cent of all drive-offs were carried out by repeat offenders. That risk is substantially reduced when blacklist data is shared across a network.
For a multi-site operator, the recommended architecture is a central blacklist service that each site's middleware polls on a schedule and caches locally. The cache means that a network outage does not disable the blacklist check. Each site can also write new entries to the central service when a confirmed drive-off or payment decline is recorded, making the list self-improving. When you call NPR API, the returned registration is just a string; the blacklist match is performed by your own service against your own dataset. This keeps you in control of what constitutes a block-worthy entry, how long entries persist and what review process a plate must pass before being listed, all of which are directly relevant to GDPR compliance.
Handling NMOP: When Payment Is Declined After Fuelling
No-means-of-payment incidents are distinct from drive-offs. In an NMOP case, the customer fills the tank, enters the shop and declares they cannot pay. According to the British Oil Security Syndicate, around £55 million was lost to NMOP incidents across UK forecourts in 2024, compared with approximately £27 million in drive-offs, making NMOP the larger loss category by a significant margin. Because the vehicle has not moved off, your ANPR system will already hold a recognised plate and the associated transaction record from the pump-event log. The workflow at this point shifts from prevention to rapid documentation.
Your middleware should automatically flag the transaction with an NMOP status, timestamping the payment-decline event and attaching the plate string, vehicle data and pump image to an incident record. That record can then be passed to a debt-recovery workflow or to industry reporting systems. Critically, the plate should be added to the blacklist for that site and propagated to the network, so that if the vehicle returns before the debt is resolved, staff are alerted before the pump is authorised again. Do not rely on staff memory for this step; the propagation should be automatic on NMOP confirmation.
GDPR and UK Data Protection
Processing vehicle registration marks for pump authorisation is processing personal data under UK GDPR, because a plate can be traced to an individual through the DVLA keeper register. The lawful basis most operators rely on is legitimate interests: the prevention of theft is a genuine, pressing interest that a reasonable person would recognise as proportionate. You should document this in a legitimate interests assessment and record it in your register of processing activities.
Zero-retention processing is the most defensible approach for vehicles that are not on a watchlist and complete a normal paid transaction. In this model, the plate string and associated image are used to run the blacklist check and link the transaction, then discarded at the end of the session rather than retained in a searchable database. Plates that trigger a watchlist hit, or that are associated with an NMOP or drive-off incident, have a clear lawful basis for retention tied to the specific incident and the legitimate recovery process.
Staff alert screens should display only what is operationally necessary: the alert level, the relevant pump number and a brief instruction such as "request pre-payment before authorising." They should not display the keeper's name, address or any data pulled from external sources beyond what the ANPR system itself captured. This minimises data exposure and keeps the processing proportionate to its purpose.
Testing and Go-Live Checklist
Before going live, measure end-to-end latency from camera trigger to pump-hold signal under your expected peak throughput. If your forecourt has eight pumps and a busy lunchtime sees four simultaneous arrivals, your middleware must handle concurrent API calls without queuing delays that blow the authorisation window. Set a hard timeout of two seconds, after which the fallback policy kicks in automatically.
Test every branch of your decision logic with known plates: a whitelisted plate, a blacklisted plate, an unknown plate above confidence threshold, a low-confidence read and a simulated API timeout. Confirm that the forecourt controller receives the correct signal in each case and that the EPOS transaction log contains the expected plate annotation. Test night-time capture with your IR configuration before go-live, not in the morning when the car park is empty. Run a simulated NMOP incident end to end, verifying that the plate propagates to the blacklist and that a second visit by the same vehicle triggers a staff alert.
Log every API call, every decision and every controller signal with a timestamp and a transaction reference. This log is your audit trail for disputed blocks, staff complaints and regulatory enquiries. Retain it in accordance with your documented retention policy.
Building the Proactive Forecourt
The shift from reactive debt recovery to proactive pump gating is not a theoretical aspiration. It is the direction the industry is actively moving in 2026, driven by theft volumes and loss values that independent operators cannot sustain. Drive-offs are up 62 per cent year on year, NMOP losses outstrip drive-off losses by roughly two to one, and the police close the majority of cases without identifying a suspect. Waiting to recover the debt after the event is an increasingly indefensible position.
The architecture described in this guide, a canopy camera feeding a recognition API, a middleware decision engine and a direct signal to the forecourt controller, is achievable with standard IP cameras, an on-site server or edge device and a reliable plate recognition API. NPR API accepts a standard multipart image upload and returns a plate string, a confidence integer and optional DVSA vehicle data in a single JSON response, which is all the structured output the decision logic requires. Full API documentation, including batch processing for high-throughput sites, is available at nprapi.com/docs.