The migration nobody wants to run
Ask an operator why they haven’t turned on ad-hoc card payments yet, and the answer is rarely “we don’t want to.” It’s “we can’t afford the project.” In their head, “add payments” has already mushroomed into a rip-and-replace: new terminals, a new acquirer relationship, maybe a new CSMS that finally speaks payments natively, a fiscalization integration per country, and six months of a systems integrator billing while the network keeps running on the stack that already works.
So they wait. They run a QR code that dumps drivers into a web form, or an app nobody downloads, and they tell themselves AFIR compliance is a next-year problem.
It isn’t a next-year problem, and it was never supposed to be a forklift. The fear is real, but the project is the wrong shape. Payments are an additive layer, not a replacement. You keep the chargers, the CSMS, the bank — and you layer the money flow onto what’s already deployed.
What you actually already have
Walk the stack of a typical operator and you find more working parts than the rip-and-replace story admits.
The chargers are deployed and talking to a CSMS over OCPP. That link is healthy: it’s how sessions start, meter values flow, and CDRs get produced. Touching it is pure risk for zero payment benefit.
The CSMS is configured, monitored, and integrated into whatever back office bills and reports today. Replacing it to “get payments” is the most expensive way to solve a problem the CSMS was never meant to solve.
And many operators already have some terminal integration — a card reader wired to a charger, a pilot at a flagship site, an early DC unit shipped with a reader because AFIR required one. It half-works. It takes a tap. What it doesn’t do is run the aftermath of the tap correctly.
That’s the seam. The hardware and the network are fine. The thing that’s missing — and the thing that quietly breaks — is everything after the card is presented.
The tap is the easy 5%
Authorizing a card at an unattended charger is close to a solved problem. A modern terminal takes the tap, places a pre-authorization for an estimated amount, and tells the charger to start. Contactless means a phone wallet works too, so Apple Pay and Google Pay come along for free. That part demos beautifully.
Then the session runs, and the other 95% shows up:
- The driver pulls the plug at half charge and walks off. You authorized for a full charge. Now you owe a partial capture and a refund of the unused hold — promptly, or the next bank statement generates a support ticket.
- The session drops mid-charge. Who finalizes, and against what amount?
- The finalization call to the acquirer fails. Retry, or you’ve delivered energy you never captured.
- The CDR from the charger and the settled amount at the acquirer disagree. Something has to reconcile them, and a human can’t do it per session at scale.
- A receipt the tax office will accept has to make its way back to the driver — a fiscal round trip, country by country, that no protocol carries for you.
This is the gap OCPI leaves open by design. The DirectPayment module standardizes the connection — a Terminal object, a pre-authorization tied to a tariff, start/stop, a Financial Advice Confirmation carrying the final settled amount. It deliberately says nothing about pre-auth strategy, the non-happy paths, fiscalization, or staying correct as APIs move. Optechain sits as an OCPI Full Contributor on exactly this work — close enough to the standard to know precisely where it stops.
So the honest pitch is narrow: you keep the terminal integration you already have; Bolt takes over everything that breaks after the tap.
What reconciliation actually compares
“Reconcile” sounds like a back-office chore until you watch a single session do it wrong.
Every charge produces two independent records of the same money. The charger and CSMS produce a CDR — an energy line: kWh delivered, the tariff applied, the amount the session should have cost. The acquirer produces a settlement record — the amount that actually moved off the card, after the pre-authorization, the partial capture, and the refund of whatever you held but didn’t use.
When those two numbers match, you do nothing. The work is in the mismatch: a hold that never released, a capture against a session that dropped, a CDR that arrived late so the settled amount finalized first, a refund the acquirer accepted but the back office never saw. Each is a different failure with a different fix, and at network scale they arrive faster than anyone can clear by hand. The engine matches the CDR line to the settled amount per session, flags the discordant ones, and tells you which kind of disagreement you’re looking at — so the exceptions queue is small and named, not a spreadsheet you reconcile on the last day of the month.
Why the fiscal round trip is per-country hard
The receipt is where most “we’ll add it later” plans quietly fail.
A legal fiscal receipt is not a PDF you generate and email. In country after country it’s a round trip. The transaction goes to an invoicing provider, the local tax rules produce a signature or a stamp, and that signed artifact has to travel back to the unattended terminal and out to the driver — in a format that specific authority will accept. Some regimes want real-time, per-transaction submission; others accept batched reporting; the required fields, the signature scheme, and the timing all differ by jurisdiction.
OCPI hands you the settled amount and stops. The receipt — the part the driver actually keeps — is the part nobody wants to build twice.
Bolt bridges that round trip both ways, per country, so the artifact the driver receives by link is a receipt the tax office accepts — not a document that merely looks like one. That is the part that turns “we support a few sites” into “we operate across Europe.”
Additive, over OCPI, on top of the stack
Here’s the part that makes this a feature toggle rather than a project.
Bolt bridges payments over OCPI, not over a bespoke link welded to one charger model. Your chargers keep talking to your CSMS over OCPP exactly as they do today. Bolt speaks to the payments layer through the standard interface the CSMS already exposes. Nothing in the energy path gets re-plumbed.
That single architectural choice is what kills the forklift. Because the integration rides the standard interface — not a proprietary terminal soldered to a specific charger firmware — the things operators are terrified of touching simply don’t move:
- Your bank stays your bank. Funds settle to your acquirer; the merchant of record stays you. Bolt is non-MoR — the money never routes through us. You keep card-present terms rather than being pushed onto card-not-present treatment for small AC sessions.
- Your CSMS stays your CSMS. It’s reached over OCPI, so it doesn’t get replaced to “support payments.”
- Your hardware stays your hardware. Any modern terminal, any charger model behind any CSMS. The terminal you already wired up keeps doing the one thing it’s good at — taking the tap.
What gets added is the engine: pre-authorization strategy, partial captures, refunding unused holds, finalization retries, the reconciliation above, and the per-country fiscal round trip that turns a charge into a receipt the tax authority accepts. Because Bolt holds no card data in the open — the terminal and acquirer handle the sensitive path — your PCI DSS scope stays minimized rather than expanding with every site you add.
Start with one site, not the network
Because it’s additive and interface-based, the rollout can be as small as you’re comfortable with.
Turn it on at one location. A DC site is the natural first candidate: those sessions are fast, high-value, and reliability-critical, and DC hardware is expensive enough that you want the money flow provably correct before you scale. Run live sessions through the new layer while the rest of the network keeps doing whatever it does today. Compare the reconciliation output against your back office. Watch a real partial capture and a real refund settle to your acquirer.
If the operator already has a half-working reader at that site, you’re not throwing it out — you’re putting a correct engine behind it.
The driver’s experience is the proof it’s working, without an app in sight: park, walk up to a charger they’ve never seen, key in an amount, present a card, charge. Status by SMS link, a legal fiscal receipt by link at the end, stop early by unplugging or pressing a button. No download, no account, AFIR-aligned — on hardware you already own.
Reversible is the whole point
The cheapest migration is the one where nothing moves. A migration you can’t back out of isn’t low-risk; it’s a bet. This one is built to be undone.
Because Bolt never becomes your merchant of record and never sits in the funds path, there’s no money entanglement to unwind. Because the bridge is OCPI rather than a proprietary weld, there’s no firmware fork to rip out. Swap a terminal, change acquirers, add a country, or walk away from the payments layer entirely — your chargers, CSMS, and bank are exactly where they were, because they never moved.
The rip-and-replace everyone fears assumes payments are load-bearing — that to get them you must rebuild the network around them. They aren’t, and you don’t. You already built the hard, expensive part: chargers in the ground, talking to a CSMS, settling to a bank. The tap was always the easy 5%. Add the engine that handles the other 95%, prove it at one site, and leave everything else exactly where it is.