The last access method without a rulebook
Pull up to a fast charger you have never used. Tap a card. Charge. Drive away. No app, no account, no membership. It is the simplest thing a public charger can offer a driver — and until recently it was the only way in with no shared rulebook behind it.
Every other path had one. App flows ship with SDKs. Plug & Charge runs on certificates and contract provisioning. The walk-up card terminal lived in the gap between them: an operator who wanted it wired a reader to a specific charger model, against a specific acquirer, and shipped. Each of those builds was sound on its own terms. The trouble was that none of them could speak to one another, and none outlived the firmware it was born on.
That gap is now closed inside the standard itself. Working through the EV Roaming Foundation — the same forum that gave the industry sessions, CDRs, and roaming tariffs — the community defined ad-hoc terminal payments as DirectPayment, built inside OCPI. It is a deliberately small piece of specification. The restraint is the whole point, and it is worth being precise about where the restraint lands.
Two objects, and a hard line around them
DirectPayment adds exactly two objects, and pointedly refuses to add a third.
The first is a Terminal object. Before it, the card reader was something the operator knew about and the network did not — an implicit fixture with no seat in the data model. Now it is a first-class entity. But be exact about what kind: the Terminal is a mapping. It carries a terminal identifier, the locations and EVSEs the reader serves, a reference back to the operator’s OCPI backend, and a base address for the invoice. Its entire job is to let the network attribute a session and a receipt to a specific physical reader standing in front of specific charge points.
What it is not is a controller. It binds no tariff. It owns no pre-authorization. Start and stop do not hang off it — that stays the work of OCPI’s existing command and tariff modules, exactly as before. The Terminal is the missing noun that ties an unattended reader to the rest of the OCPI graph. Nothing more.
The second object is a Financial Advice Confirmation: the settled-amount message. When a session ends and the acquirer holds the real captured figure rather than the estimated hold, the terminal side pushes this confirmation — the final cost, the currency, the data an invoice needs, and a capture status that can read success, partial success, or failure.
That capture status carries more weight than it first looks. The most expensive disagreement in unattended charging is the one where the charger says one thing and the money says another. A shared settled-amount message — one that treats partial and failed captures as named, first-class outcomes rather than edge cases each integration reinvents — gives both sides a single artifact to reconcile against. It turns a reconciliation argument into a field lookup.
So that is the standard: a terminal mapped to its EVSEs, and a confirmed amount with a capture status. It standardizes the connection, so a conformant reader can speak to a conformant CSMS without a bespoke bridge wedged in between.
A protocol defines the handshake, not the engine
A good standard draws the interface and stops. DirectPayment holds that line, and reading what it leaves out tells you what it is for.
It says nothing about pre-authorization strategy — one fixed hold, incremental re-authorization as the kWh tick up, or a driver-named target amount before charging. Each choice pushes decline rates, driver experience, and cash flow in different directions. That is product, not protocol, and the spec is right to stay quiet.
Beyond naming a capture status, it says little about the unhappy paths. Plenty still has to be handled outside the spec:
- A partial capture reconciled against the session record.
- The unused portion of a pre-authorization hold released back to the driver.
- A failed finalization retried without double-charging.
- A session that drops mid-charge resolved into a defensible amount.
- A CDR and an acquirer that simply disagree, adjudicated by something.
And it carries nothing for fiscalization — turning a settled amount into a legally valid receipt, a market-specific round trip the protocol was never going to model. The giveaway is structural: the Financial Advice Confirmation exists because the CPO issues the invoice. The spec hands over the number, then leaves the receipt entirely to the operator.
This is the familiar shape of every standard that has aged well. OCPP tells a charger and a CSMS how to talk; it never tells an operator how to run a business on top. OCPI’s session module never told anyone how to bill. DirectPayment, in the same spirit, does not tell anyone how to run the money. The handshake is standard. Everything that turns a settled figure into a compliant receipt — and keeps doing so as acquirer APIs shift, OCPI versions bump, and CSMS releases land underneath — is something a CPO either builds and maintains forever, or sources once. That is not a flaw. It is the correct division of labor between a protocol and a product.
What naming the connection quietly settles
Before DirectPayment, a private bridge was the only honest answer. If a driver had to tap a card today, you wired the reader you had to the charger you had, against the acquirer you had, and shipped. The engineers who built those bridges were not cutting corners — they were solving a real problem with no standard to lean on, and many of those integrations worked beautifully for the hardware and market they were built for. Crediting that is only fair.
The trade-off is architectural, and it surfaces the moment anything underneath moves. A bridge tied to one charger model, one acquirer, one firmware encodes today’s assumptions everywhere at once. Swap the charger and it is rework, not reuse. The day a dependency ships a release, the bridge that was correct at install starts drifting, and someone has to chase it across every site. For the CPO, that is a maintenance liability that compounds with the estate. For the driver, it is the difference between a tap that works and a reader throwing an error nobody on site can explain.
A shared standard changes the economics. A reader and a CSMS that have never met transact on first contact, because both speak the same defined connection — the same reason OCPI already pays off for sessions and tariffs. And the contract is versioned and maintained by a community watching the seams, which is longevity a private bridge cannot buy on its own.
There is a regulatory edge, too. AFIR requires ad-hoc card payment at high-power public charging — the 50 kW-and-above tier, where a card reader or contactless device must be accepted with no operator contract. When the obligation is “any driver can pay with a card, no app,” conformance to a named, documented, open module is the cleanest evidence an operator can hold up that the rule is met. A bespoke bridge can satisfy the same requirement — it is just far harder to point an auditor at.
A private bridge optimizes for shipping this charger this quarter. A standard optimizes for every charger, every acquirer, every market, for as long as the network runs.
Those are not the same bet. The second one is the bet the industry is now making.
What a seat at the table is for
Standards do not write themselves, and they are not extended by the people outside the room. Optechain holds an OCPI Full Contributor seat through the EV Roaming Foundation — a governance position, not a logo on a partner page. Ad-hoc terminal payments becoming a first-class part of OCPI is precisely what such a seat is for.
The signal runs two ways. The open approach to terminal payments is winning on the standards track, not just in slide decks: the Terminal object and the Financial Advice Confirmation exist because operators and infrastructure builders agreed they should, in the forum that governs the rest of OCPI. And the engine that runs the money is built by people present when the interface it speaks is sharpened — which is the difference between integrating against a finished spec and being in the room when its next version has to tighten a refund path or a partial-capture nuance that today’s draft only names.
For an operator, the practical reading is simple. Bolt EV bridges payments over DirectPayment so one integration holds across charger, CSMS, terminal, and acquirer — and the operator stays the merchant the entire way through. Funds settle to the operator’s own acquirer as a card-present transaction; they never route through Bolt. The CSMS stays the operator’s, spoken to over OCPI. The reader, the acquirer, the market can all change without breaking the integration, because the integration is to a standard, not to a vendor.
The thinness is the contribution
DirectPayment is thin on purpose. The terminal is now a first-class object. The settled amount is now a defined message. And everything genuinely hard about running the money — strategy, recovery, fiscalization, routing, staying correct as every layer underneath keeps shifting — is left exactly where it belongs, outside the protocol.
That space does not fill itself. It is an engine you build once for a market and maintain, or rebuild forever, one charger at a time. The community has settled the connection. The only open question left for an operator is whether to carry that engine alone — or speak the standard through one that is already running.