Held, Not Taken: Turning Pre-Authorisation Into a Real Screen in UK Fuel and EV Apps

Picture the scene. It’s 7:40am on the A34, the driver taps their card at the pump, the app says “Authorising…”, and then the screen drops back to the home tab. No fuel, no clear reason, and a £1 pending transaction sitting in their banking app. By 7:45 they’re ringing support. By 7:50 they’ve left a one-star review that mentions the word “scam”.

The hold itself is not the problem. The problem is that most UK fuel and EV charging apps treat pre-authorisation as plumbing rather than product. The driver sees money leave their available balance, even though no money has been taken. If your app doesn’t explain that moment properly, the rest of the journey — pump, charger, receipt, refund — becomes a trust exercise the user never signed up for.

The bit the bank statement gets wrong

A pre-authorisation is a check, not a charge. Fuel retailers often place a small hold — the famous £1 — before releasing the pump, then settle the real amount later. Some sites use larger holds, especially for pay-at-pump and HGV lanes. Public EV charging networks do something similar: a £1, £5, £25 or £50 hold depending on the network and the session. The final amount replaces it when the session closes.

But users don’t see the logic. They see a pending line on a Monzo or Starling feed and assume the worst. Fleet drivers see it next to an Allstar or fuelGenie card and wonder whether they’ll have to explain a duplicate spend to the office. The app’s job is to make the pending state legible before the user reaches the support queue.

Pump flow: the hold starts before the nozzle

At a pay-at-pump site, the sequence is roughly: card check, pump unlock, fill, settle. Your app only owns the first and last parts, which is exactly why the middle needs honest copy. “Checking your card — this is not a £1 charge” is better than a spinner. “Pump authorised. The final amount will replace the hold” is better than silence.

If the pump fails to unlock, say so before the user walks away. If the card check fails, don’t leave them staring at a blank forecourt screen. Give them a reference, a timestamp and a route back. If the pump dispenses fuel but the app loses connection, don’t pretend the session vanished. Queue the state locally and reconcile when signal returns. The canopy at a motorway services is not a reliable data centre.

Charger flow: holds that outlive the session

EV charging adds a second wrinkle: the hold can sit there while the session is still running. A driver plugged in at a Gridserve or Osprey site on a wet Tuesday may see a £25 pending amount and assume they’ve been overcharged before they’ve even had a coffee. If your app shows “£25 held” without “final cost will replace this when you unplug”, you’ve created a support call.

Design the charger screen around three states: held, charging, settled. Show the hold amount and the network’s release wording. If there’s an idle fee, say when it starts and whether it affects the hold. If the session fails before any kWh are delivered, trigger the release and tell the user you’ve done it — not just that the hold “should” drop off.

The offline problem: canopies, car parks and cows

UK signal is not a flat surface. Petrol station canopies, underground car parks, rural A-roads and the sort of barn conversion that doubles as a charging hub all punish naive real-time designs. Don’t build a payment flow that needs a perfect handshake at the exact moment the user is standing in the rain.

Use a local pending record with a clear reference. Let the app show “we’ll update this when we reconnect” rather than a false failure. On reconnect, reconcile in the right order: authorisation, session, settlement, receipt. And make sure your support team can see the same reference the user sees. Nothing slows a call faster than the agent asking for a transaction ID the app never displayed.

Refunds, release times and the bank’s calendar

Here’s the sentence that belongs in your help centre: “We release the hold immediately; your bank may take 1–3 working days to update your available balance.” That’s usually true. Sometimes it’s longer. The app should timestamp the release on your side so the user knows the delay is with the issuer, not with you.

This matters around bank holidays and school breaks. A hold placed on the Friday before a bank holiday can feel like a weekend-long charge. If your support script says “it will drop off shortly” without a date, you’ve chosen vibes over evidence. Give the agent a release timestamp, an authorisation code and an escalation path for anything older than seven days.

VAT receipts and fleet cards

A pre-authorisation is not a VAT receipt. UK drivers and fleet administrators need the final document: the amount, the fuel or kWh, the VAT breakdown and the site details. For EV charging, that means showing kWh and the VAT treatment clearly, because a domestic-style charge and a public charging session are not the same thing on an expense claim. For fuel, it means a receipt that survives the finance team’s scrutiny, not a screenshot of a pending amount.

Fleet cards add pressure. A driver with a company fuel card may see a hold against a card that has a strict spend limit. If the hold is £1, fine. If it’s £100, the next fill-up might decline. Build a fleet-friendly view: show the hold, the final amount, the vehicle or site reference and a downloadable receipt. Give the back office a reconciliation file that matches authorisations to settlements. Otherwise your app becomes a monthly argument between drivers and finance.

Support scripts you should write before launch

Write the macros before the first user sees a pending line. “The £1 is a temporary card check, not a charge.” “We released the hold at 08:14; your bank controls the display.” “Here is your authorisation reference.” “If it is still pending after seven working days, reply to this message and we will escalate with the acquirer.” Then test those scripts with someone who has never worked on payments. If they can’t explain it back, the script isn’t finished.

A short launch checklist

Label the pending state in plain English. Show the amount and the release timestamp. Explain what replaces the hold. Provide a final VAT receipt, not just a confirmation screen. Support offline sessions without duplicating charges. Give fleet users a reconciliation reference. Train agents on the difference between a hold and a charge. And test the whole thing on a real card at a real pump and a real charger, on a day when the signal is rubbish. That’s the launch readiness test that matters.