The asset tells you everything
Walk up to a DC fast charger and you are standing next to something that can cost an order of magnitude more than an AC unit. That gap is not trivia. It changes what the payment around it has to be.
The instinct in most rollouts is to pick one payment design and stamp it everywhere — same hold, same hardware, same flow, AC or DC. It feels clean. It is actually a compromise that fits neither, because the two are different transactions wearing the same uniform.
An AC session is slow, frequent, and low-value: a driver plugs in for hours, often overnight, and the bill is small. A DC session is fast, high-value, and reliability-critical: the driver is standing there, the energy is expensive, the queue behind them is real. A payment that fumbles at a fast charger is a far more visible failure than one at a curbside post.
Pricing the hardware differently is obvious. Pricing the money flow differently is the part everyone skips.
The hold is not one number
The pre-authorization is where AC and DC stop agreeing.
On a DC charger, a session can run to a meaningful sum in fifteen minutes. The hold has to be large enough to cover a fast, expensive fill, or you risk under-authorizing and eating an uncollectable balance. But a large fixed hold is exactly the thing that triggers declines — especially on debit, and on cards from issuers that treat big unattended holds as suspicious. So the most valuable sessions are also the ones most likely to be refused at the door. That tension is the whole design problem.
On an AC charger, the economics invert. The session is small and slow, so a big hold is overkill and a needless decline risk — but the thing that actually bites is small-session economics. When the bill is modest, every fixed cost on the transaction is proportionally enormous. A hold strategy that is fine on a high-value DC fill can quietly make a low-value AC session uneconomic. The cents matter most exactly where there are fewest of them.
This is why a single pre-auth strategy is the wrong answer. The OCPI DirectPayment module standardizes the connection — a Terminal object, a pre-auth tied to a tariff, a Financial Advice Confirmation that ties the captured amount and the EFT data back to the session — but it deliberately says nothing about which strategy you pick. And the strategy is not one choice; it is a family:
- One fixed hold. Simple and predictable, but you either over-hold (declines) or under-hold (shortfall). Tolerable on a known, capped AC session; risky on an open-ended DC fill.
- Incremental re-authorization. Hold a base, top it up as energy flows. Keeps the initial hold small enough to clear, then scales to whatever the session actually becomes. This is what a high-value, variable DC session wants — and it is more moving parts, more acquirer round-trips, more non-happy paths to get right.
- Driver-declared target. Let the driver key in an amount, authorize that, charge to it. Ideal for AC, where someone caps it at a round number and walks away. It maps cleanly to the park-walk-tap flow and to a slow charge nobody is watching.
Each of these swings decline rates, cash flow, and the driver’s experience in a different direction. The right pick on a DC charger is often the wrong pick on the AC unit in the next bay.
The non-happy paths diverge too
The strategy choice drags the failure handling along with it — and that is where the real cost of getting this wrong lands.
A fixed hold on a small AC session means refunding the unused remainder on almost every transaction. Do that thousands of times across a dense AC cluster and refund handling becomes a real operational line, not an edge case.
Incremental re-auth on DC carries the opposite burden. A session can drop mid-charge with a chain of partial holds outstanding, and you have to unwind them cleanly. You have to reconcile when the charger’s reading, the CDR, and the acquirer’s settled amount disagree on a transaction large enough that the disagreement actually hurts.
The stakes per failure are higher on DC; the volume of failures is higher on AC. Different problems, both real, neither solved by pretending the two profiles are one.
Hardware and deployment are downstream of the session
The payment hardware follows the same split.
A high-power DC charger needs its own contactless card-present reader — required on qualifying new units (at the AFIR power threshold) from April 2024, with existing units on core road and parking networks retrofitted by January 2027 — and it makes sense to treat each one as a self-contained payment point. The session is high-value and reliability-critical; you do not want one driver’s payment hardware to be a single point of failure for a whole bank of fast chargers. A terminal per charger is the right granularity when each charge is worth defending.
An AC cluster is the opposite. You have a row of slow, low-value posts, often in a car park or a depot, and standing up a full card terminal on each one is the small-session economics problem made physical — you are amortizing hardware across sessions that individually barely justify it. A shared payment point for the cluster — one place a driver authorizes, tied to the bay they plugged into — is frequently the better deployment. Lower-power AC is also where AFIR opens up a QR or payment-link route rather than a mandated card reader, and that flexibility lands exactly where the per-charger terminal makes least sense.
So you end up with two genuinely different physical layouts — terminal-per-unit on DC, shared payment point on an AC cluster — derived from the same root fact: what is one session worth, and how often does it happen?
One engine, two configurations
Here is the part that makes the two-profile reality manageable instead of a maintenance nightmare: the differences are all configuration, and they sit above a layer that should be identical.
Chargers talk to their management system over OCPP. Bolt bridges the payments over OCPI, so the same engine drives a DC unit and an AC cluster regardless of who made the charger, which CSMS runs it, or which terminal is bolted on. The pre-auth strategy, the hold size, the re-auth behavior, the deployment topology — those are dials.
The thing underneath the dials is one implementation, exercised by every session of either kind:
- capturing the real amount and refunding the unused hold
- surviving a dropped session and unwinding partial holds
- reconciling when the charger and the acquirer disagree
- producing a fiscal receipt the tax office accepts, via the country-specific round trip OCPI carries nothing for
That is the argument for building the money engine once rather than welding a bespoke setup to each charger model. If DC and AC each got their own hand-rolled payment stack, you would have two things to keep correct forever as acquirer APIs, OCPI versions, and CSMS releases move. With one neutral engine, you keep your own acquirer and card-present economics on both, and the only thing that varies between a fast charger and a slow one is the dial setting that should vary.
The takeaway
DC and AC do not want the same payment because they are not the same transaction. One is fast, expensive, and watched; the other is slow, cheap, and frequent. Force them through a single hold, a single terminal, a single deployment, and you have built something that over-serves the cheap session and under-serves the valuable one.
The fix is not two payment systems. It is one engine that knows the difference — fast or slow, watched or not — and makes that difference a setting instead of a separate stack to maintain.