The pre-authorization is the only decision in a charging session that can lose you the sale before the session even starts — and most integrations make it on autopilot.
Everyone treats it as plumbing. It is the product. Get it wrong and you lose the driver at the worst possible moment: card in hand, committed, charger idle. Get it right and the session feels like tapping for coffee.
One number, three completely different products
OCPI’s payments model gives you a clean slot: a pre-auth tied to a tariff, a start, a stop, and a Financial Advice Confirmation — OCPI’s settled-amount message — at the end. One amount in, one amount out. The data model is honest about what it carries and silent about what it costs you.
Because behind that single field sit at least three strategies, and they are not interchangeable. They diverge on the three axes that actually matter:
- Decline rate — how often the hold bounces at the terminal.
- Driver trust — what the amount on hold feels like to the person watching it.
- Cash flow — how much of someone’s credit you freeze, and for how long.
The default most integrations reach for is the worst on all three.
Strategy one: the fixed wall
You don’t know how much the driver will charge, so you hold a big round number to be safe — a generous ceiling that covers the longest plausible DC session.
This is the path of least engineering resistance, and the most expensive in every way that matters.
A large hold raises declines. The bigger the authorization, the more cards bounce it: thin limits, prepaid cards, debit accounts living close to zero, an issuer’s risk model that doesn’t like a stranger asking for a lot at an unattended machine in a country the cardholder isn’t in. Every one of those is a driver who did everything right and still can’t charge.
It also corrodes how the session feels. A driver who wanted a modest top-up watches a far larger sum vanish from their available balance, sometimes lingering well after they’ve driven off, until the issuer unwinds it. They don’t read it as a hold. They read it as your charger taking their money. They don’t come back, and they tell people.
And it quietly freezes credit — you’ve parked a chunk of someone’s available limit against a small sale. Multiply that across a network and the fixed wall is a tax on adoption disguised as caution.
The fixed wall optimizes for the operator’s fear of under-collecting. It pays for that comfort with declines and churn.
Strategy two: incremental re-authorization
Instead of one big guess up front, you hold a small amount to open the session, re-authorize in steps as the kWh climb, and release what you never needed at the end.
This is the right shape for open-ended sessions where neither you nor the driver knows the final number: a long DC stop, a car left to fill to 80%, anything where “how much” is genuinely unknown at tap.
The first hold is small, so few cards refuse it — easy to approve, friendly to thin and prepaid cards. The visible amount tracks reality instead of dwarfing it, so there’s nothing for the driver to misread. And you never tie up credit you won’t use.
The cost is moved into your engine. Incremental re-auth means orchestrating a sequence of authorizations against the live session, each of which can fail on its own: a re-auth declined mid-charge, a hold that expires before the session ends, a card that was fine at tap and isn’t ten minutes later. You need a policy for every one of those that isn’t “drop the session and strand the driver.” And at the end you reconcile the staircase of holds against the final settled amount, then refund the slack — cleanly, every time.
That staircase climbs against something real: the meter values the charger streams back to its CSMS over OCPP are the energy truth your re-auth steps are tracking. OCPI won’t carry the strategy for you — it models the endpoints, the pre-auth and the Financial Advice Confirmation. The steps in between, and the non-happy paths hanging off each one, are yours to build and yours to keep correct as acquirer APIs shift underneath you.
Strategy three: the driver-declared target
You ask. The driver names an amount — a sum, a kWh target, “fill it” — and you place a hold near that figure rather than at a worst-case ceiling.
This is the quiet winner for the card-present, ad-hoc flow the whole AFIR-aligned experience is built around: park, key in an amount, tap, charge. The driver told you what they want; the hold matches intent instead of fear.
Approvals rise because the hold is sized to a real, usually modest number — not a ceiling built for the longest session anyone might ever run. Trust is highest here, because the driver set the figure themselves: the amount on hold is the amount they asked for, with maybe a thin buffer for tariff rounding and tax. There’s nothing to explain. And the credit picture is clean on both sides — you collect against a declared target, and the unused remainder of a session that ends early (driver unplugs, hits stop, car tapers off) gets released or never captured.
The catch is finalization discipline. Driver-declared works only if the closeout is exact. If they declared a target and charged less — stopped early, the car was nearly full — you must capture only what was delivered and release the rest, fast enough that the driver sees it.
A driver-declared target with sloppy refunds is just a fixed wall wearing better UX.
The strategy is a function of the session, not a setting
There is no single correct answer — which is precisely why a single OCPI field can’t encode one.
AC sessions are slow, frequent, and small: overnight, at-work, top-ups. The hold is modest and the risk of a big over-collection low, so a tight driver-declared target or a small fixed hold sized to a typical session is usually fine, and the engineering should stay light.
DC sessions are fast, high-value, and genuinely open-ended — exactly the conditions where a fixed wall does maximum damage. A high-power stop can run to a real sum, and the final number is unknown at tap. This is where incremental re-auth earns its complexity, often layered on a driver-declared starting point. The hardware is the expensive part of a DC site; the pre-auth decision is what determines whether that hardware actually closes sales.
Then card type cuts across both. A prepaid or thin-limit debit card tolerates a small opening hold and incremental top-ups far better than one large authorization — the difference between a charge that starts and a decline at the terminal. A strategy that ignores card type optimizes for the cards that least need the help.
So the real design space isn’t “pick a strategy.” It’s a matrix — AC versus DC, session length, card type, and the fiscalization round trip waiting at the end — and the right cell changes per session, sometimes per tap.
Why this is the engine, not a config flag
OCPI did its job. It standardized the connection, so a hold placed through any terminal — settling to the operator’s own acquirer, against any CSMS over OCPP — speaks the same language. The DirectPayment module even gives the ad-hoc terminal flow a Terminal object and that Financial Advice Confirmation to settle against. That’s the handshake, and it’s genuinely useful.
But the handshake gives you one number where reality needs a decision tree — and a decision tree implies state, retries, expiry handling, partial captures, refunds of the unused hold, and reconciliation when the charger’s view and the acquirer’s view disagree. None of that lives in the protocol. All of it lives in the layer that runs the money.
That layer is the product. Pre-auth strategy is its sharpest expression — the one place where a design choice maps directly onto whether a driver charges or walks, whether they trust the network or warn their friends off it, whether credit sits frozen or flows. The operator keeps their merchant relationship and their card-present economics; what they choose when they choose Bolt is to not rebuild this matrix themselves, and to not get the default wrong.
In that half-second before a single electron moves, the hold has already decided most of what follows. Place it well and the rest of the session is easy. Place it badly and nothing downstream can save you. The pre-authorization isn’t the start of the game. It’s the whole game.