The map a single acquirer can’t cover
Draw the footprint of any one acquirer over a map of Europe and you get a shape full of holes. Strong in three or four markets, thin in the next handful, absent in the rest. No acquirer is the right answer everywhere — and that is not a failing of acquirers, it is the structure of the market. Card-scheme support, local debit rails, settlement currency, supported card-present hardware, and the commercial terms you can actually negotiate all change at the border.
So the operator who plans to charge cars in eight countries has a problem before selling a single kWh. A pan-European charging network is a multi-acquirer business by nature, and the only real choice is whether to put a layer in front that makes that fact invisible to the rest of the stack — or to wear it as a tax on every border crossing.
What “one acquirer everywhere” actually breaks
It breaks in four places at once, and they compound:
- Coverage. Your acquirer may simply not be licensed, or not settle, in a given market. A card-present transaction that can’t be acquired locally either fails or gets force-fit through a cross-border path — saddled with card-not-present markups built for e-commerce risk, the kind that make a small charging session uneconomic.
- Local card schemes. Several markets lean heavily on domestic debit schemes that a foreign acquirer routes poorly or not at all. If a meaningful slice of drivers in a country carry a card your single acquirer treats as exotic, your decline rate there quietly climbs — and you never see why.
- Currency. A session priced and authorized in the local currency, then settled to an acquirer that books in another, drags an FX conversion and a reconciliation seam into every transaction. Multiply that across a continent of small sessions and the spread stops being a rounding error.
- Commercial terms. Rates and certification scope differ per acquirer, and so does a cluster of operational detail — supported terminal models, dispute handling, the shape of the reconciliation file. Standardizing on one acquirer means accepting its weakest market as your baseline everywhere.
None of these are visible on day one in your home market. They surface as you cross borders: a higher decline rate here, an FX line there, a country you can’t enter without a second integration. That is the trap. One-acquirer-fits-all doesn’t fail loudly — it taxes you quietly and caps your map.
The expensive default: integrate per market
Faced with this, most operators do the obvious thing and integrate a second acquirer for the second region. Then a third. Each one is its own project: a different API shape, different pre-authorization and capture semantics, a different reconciliation file, a different certification pass, a different set of non-happy paths to handle when a hold needs releasing or a finalization fails.
And every one of those integrations is welded into the part of the system that runs the money — the same code that handles pre-authorization, capture, partial refunds, and the financial-advice confirmation at the end of a session. Now you maintain that logic N times, once per acquirer, and you re-test all N every time an acquirer ships an API change.
This is the per-market re-integration tax. It doesn’t just cost the integration; it costs the maintenance of every integration, forever — and it turns each new country into a full engineering quarter rather than a configuration change.
Routing is the product
The alternative is to treat the acquirer as a destination, not a dependency, and put a routing layer in front of all of them.
The operator integrates once, to the payments layer. The session carries what the layer needs to decide: which country the charger is in, what currency the tariff is denominated in, which card the driver presented. The layer maps that to the right acquirer for that country and currency, applies the correct pre-authorization strategy and capture behavior, and runs the full lifecycle — hold, top-up or release, capture, refund, finalization — against whichever acquirer it routed to.
The charging stack above never learns the acquirer’s name. It hands over a session and gets back a settled amount. Adding the ninth country becomes onboarding an acquirer behind the layer and switching on a route — not another welded integration in the charging application.
Because Bolt bridges payments over OCPI rather than welding a bespoke POS to one charger model, this works against any CSMS, any terminal, any acquirer. The charger talks to its CSMS over OCPP; the payment terminal is whatever the site already runs; the route underneath can change without any of them noticing. The driver’s experience — walk up, key in an amount, tap a card or a phone wallet, get a status link and a legal receipt — is identical whether the session settles in market one or market eight.
Per-country isn’t only the acquirer
Routing by country is bigger than picking who settles the money. The same per-market boundary that splits acquirers also splits fiscalization.
A receipt the tax office accepts is a country-specific round trip: the fiscal signature travels from a fiscalization provider — often the same component that handles invoicing — to the unattended terminal and back, and the rules change per jurisdiction. OCPI carries nothing for this; it standardizes the connection up to the financial-advice confirmation and stops. So the layer that routes a session to the correct acquirer is also the natural place to route it to the correct fiscalization path — so the receipt that lands in the driver’s hand is valid in the country they are standing in, not a generic PDF.
The currency a session is authorized in, the acquirer it settles to, the VAT treatment, the fiscal signature: these are all facets of the same per-country decision.
Centralizing that decision in one layer is exactly what lets a single integration behave correctly in many markets at once.
The point that’s easy to miss: the operator stays the merchant
Routing across acquirers does not mean routing through a middleman. Bolt is non-MoR — not the merchant of record; it never holds or takes the money. In every country, the operator stays the merchant of record, and funds settle to their own acquirer, on card-present economics — not to Bolt, and not through some pooled account that re-bills them later.
That is the difference between an aggregator and an infrastructure layer. An aggregator becomes your single acquirer everywhere, and inherits every one of the coverage, currency, and scheme problems above — plus a markup, plus a chokepoint. The routing layer does the opposite: it lets the operator hold many direct merchant relationships and presents them to the rest of the stack as one. They keep their banking, market by market. They can swap an acquirer in one country without touching the other seven. They keep their CSMS over OCPI and can change terminal, acquirer, or country whenever the commercials or the coverage map shift.
Optechain helps shape this seam from the inside — as an OCPI Full-Contributor through the EV Roaming Foundation, with ad-hoc terminal payments standardizing as the OCPI DirectPayment extension, the open answer to the AFIR contactless-reader mandate. But the standard defines the handshake, not the routing. Deciding which acquirer settles a session, in which currency, under which country’s fiscal rules — and doing it without re-integrating per market — is the engine, not the protocol.
A network that wants to be pan-European has to decide what scales: the map, or the integration count. If every new country is a new integration into the money path, your footprint stops growing the moment the engineering does. Route the session instead, and the operator integrates once and adds countries like rows in a table — still the merchant in every one of them.