The charger is offline and the car is still drawing power
A card is tapped, a hold is sitting on it, kilowatts are flowing into a car at the side of a motorway — and the link to the backend drops. A cell tower hiccups, a roadside router reboots, a backend goes down for a routine update. The car does not care. Electrons keep flowing.
Now you have energy being delivered against a payment authorization that nobody can finalize, on a device with no human standing next to it. This is the failure mode that separates a payments product from a demo that works only on a good day. Everything else in EV payments — pre-authorization strategy, fiscalization, multi-acquirer routing — assumes the network is there. Resilience is what you build for the moment it isn’t.
And this is not an exotic edge case you can wave away. AFIR pushes contactless card acceptance onto new public chargers — the Commission’s own Q&A spells out the card-reader requirement on higher-power sites — so the roadside terminal taking that EMV tap is increasingly not optional. That makes its behavior when the link drops a compliance-adjacent problem, not just an engineering one. The standard that governs that ad-hoc roadside tap — hold, capture, the terminal and its financial-advice confirmation — is OCPI’s DirectPayment module, and it is worth knowing exactly where it stops.
What is actually at stake when the link drops
Three things are in flight, and they fail differently.
The hold is the safest of the three. It was placed before the session started, while connectivity was fine, so the funds are already reserved on the card. A dropped link doesn’t un-reserve them. The risk on the hold isn’t losing it — it’s leaving it sitting too long, or settling the wrong amount against it later.
The session is the live one. The charger and the car negotiate power over their own local link; that traffic never routes through your payments backend. So the charge physically continues whether or not the backend can hear about it. Good — the driver isn’t stranded. But energy is now accruing that the money layer has no live record of.
The capture is the one that can’t happen. Capture — settling the exact final amount against the hold — needs the final metered value, the acquirer’s API, and the fiscal round-trip, all three on the far side of the broken link. So the capture has to wait, and waiting safely is the entire problem.
The risk window
Name the dangerous interval precisely. It opens the moment connectivity drops with a session live, and it closes when the backend, the acquirer, and the fiscal layer are all reachable again and agree on one number.
Inside that window, energy is delivered that has not been settled. Do nothing, and you risk one of two failures:
- Under-capturing — the car took more than the eventual capture covers, and the difference is stranded.
- Double-charging — a naive retry loop fires the same capture twice and bills a driver who has already left.
The instinct to “just capture whatever we last saw” is how you ship that double-charge. The last value the backend saw before the drop is almost never the final value. Capture it and you strand the difference; capture it and then capture again on reconnect and you bill the session twice. Both are unacceptable at an unattended device, where there is no one on site to fix it.
So the rule is blunt: never finalize money against a number you cannot prove is final. The window stays open until the proof arrives.
Store-and-forward, and why it’s a payments primitive
The standard answer to “the network is gone but the work continues” is store-and-forward: the edge keeps doing its job and queues the durable facts to replay once the link returns. Chargers already work this way under OCPP — the charge point buffers meter values and transaction events while offline and forwards them to the CSMS on reconnect.
Payments need the same discipline, but the stakes are higher, because the queued items move money. The edge has to durably record, in order: this session started against this hold, these meter readings accrued, this is the moment the driver stopped. Not in volatile memory that a reboot wipes — on disk, idempotent, survivable.
The key design choice is that the queued payment intent is an instruction, not an action. “Capture this session for this final amount” sits in the queue as a record. It becomes a real capture only when it reaches a layer that can confirm it hasn’t already been applied.
Store-and-forward without idempotency is just a faster way to double-charge.
Deferred capture done right
So capture is deferred. The session ends — the driver hits stop, or unplugs, or the target amount is reached — and the final metered value is recorded locally, signed, and queued. The driver can walk away. The money settles when the world reconnects.
When the link comes back, three things have to line up before any money moves:
- The final amount has to be reconciled. The charger’s reading, the CDR the CSMS eventually produces, and what the acquirer is willing to settle are three numbers that should match and sometimes don’t. You reconcile to one truth before capturing — you don’t capture three times and sort it out later.
- The capture has to be idempotent. Every queued capture carries a stable identifier tied to the session and the hold. The settlement layer treats a repeat of that identifier as a no-op, so a retry that crosses a flaky reconnect — the classic “did my request actually land?” — resolves to exactly one capture. This is the single most important guarantee in the whole flow.
- The unused portion of the hold has to be released. If the driver was held for a notional amount and charged less, you capture only what was delivered and reverse the rest against the same authorization — an authorization reversal, not a refund. Leaving it to expire silently is how you generate support tickets and chargebacks; issuing a refund against a charge that was never even captured is exactly the muddle you built this flow to avoid.
Only then does the fiscalization round-trip run: the final amount goes to the country-specific invoicing provider, the fiscal signature comes back, and the driver gets a receipt the tax office accepts. That round-trip was impossible during the outage; it runs cleanly once, after reconciliation, on reconnect. DirectPayment standardizes the terminal and the financial-advice confirmation, but it carries nothing for that fiscal round-trip — so the bridge that runs it has to be the thing that survived the outage too.
Why bridging over OCPI is what makes this survivable
Here’s the structural reason this is tractable at all. Bolt doesn’t weld a payment terminal to one charger model. It bridges payments over OCPI so the same logic runs across any CSMS, any charger, any terminal. That matters for resilience specifically, because the failure modes are the same shape everywhere: a link drops, a session continues, a capture defers, a reconnect reconciles. Solve it once in the bridge and every operator inherits the same store-and-forward, the same idempotent capture, the same hold-release behavior — instead of each CPO reinventing offline handling per charger firmware and hoping the edge cases were caught.
And because Bolt is non-MoR — the operator stays the merchant, funds settle to their own acquirer, the money never routes through Bolt — the reconnect doesn’t have to reconcile across a middleman’s books. The capture lands on the operator’s own card-present rails, with one authorization, one settlement, one fiscal receipt. The neutrality that keeps the economics clean on a good day is the same thing that keeps reconciliation simple on a bad one.
The test of a payments engine is a bad day, not a good one
Any system can take a card when the network is up. The question a CPO should ask — of Bolt, or of whatever they’re tempted to build themselves — is narrower and harsher: a charger went dark mid-session, delivered energy for ten minutes offline, then came back. Where’s the money?
The right answer is boring on purpose. The hold held. The session finished. The capture deferred, reconciled to one number, and fired exactly once. The unused portion of the hold was reversed, not refunded. The receipt came back signed. The driver was never double-charged, and never noticed anything had happened.
Payments at the edge of the grid have to survive the internet not being there. Build for the drop, and the good days take care of themselves.