EV charging billing sounds simple in the abstract — a session happens, energy is delivered, money changes hands. The operational reality is more involved. A CPO running a multi-site network deals with at least four billing models simultaneously: per-kWh pricing for retail users, flat time-based fees where per-kWh billing is legally restricted (several US states have historically required this), membership tier pricing for subscribed drivers, and utility rate structures that make the cost of energy delivered vary by time of day. Getting all of that out of your OCPP session data and into your accounting system requires intentional integration architecture, not just a payment terminal.
This post covers the billing integration layer for EV charging operations: how session revenue data flows from the charge point through your CPMS to payment processors and back-office systems, where the complexity concentrates, and what to build vs. what to configure.
The Session Revenue Data Pipeline
The raw material for billing is the OCPP session record. At session end, the CPMS captures StopTransaction data: session start and end timestamps, total energy delivered (from MeterValues during the session), transaction ID, and the authorization credential used to start the session (idTag). This is the source of truth for what was delivered.
From there, the billing pipeline needs to do several things before money can move:
- Apply pricing rules. The same session data requires different fee calculations depending on the pricing tier applicable to the driver — is this a walk-up user paying retail per-kWh, a member paying a discounted rate, a fleet vehicle on a fixed monthly plan, or a roaming user arriving via OCPI whose billing is handled by their home network?
- Resolve payment method. The payment credential (RFID, app, credit card via contactless reader, or roaming token) determines both the payment routing and the applicable fee schedule.
- Calculate the charge. Per-kWh billing is straightforward; time-based billing requires parking-dwell logic to separate charging time from idle time after the session ends; idle fees (after a configurable grace period) are a separate line item in most deployments.
- Execute payment capture. For card-present or card-not-present transactions, payment is typically authorized at session start and captured at session end for the actual amount. Authorization hold amounts require configuring correctly — too low and you risk authorization failure at capture; too high and you create cardholder friction.
- Reconcile to your back office. Revenue recognized in your CPMS needs to match what's in your payment processor, which needs to match what your accounting system records. Each hop is a potential reconciliation discrepancy.
Payment Processor Integration: What the Connection Actually Requires
For CPOs using Stripe (or comparable payment processors), the integration surface is typically the Stripe Payment Intents API for card-not-present flows — common when drivers pay via an app or web portal — and the Stripe Terminal API for physical card reader deployments on charge points. The two flows have different technical requirements and different settlement behavior.
For Payment Intents (app/web), the flow is: create a PaymentIntent when the session starts with an amount slightly above the expected session cost, capture or update the amount at session end. The challenge is estimating the authorization amount correctly when you don't know the session duration or energy consumption in advance. A common practice is to pre-authorize a fixed amount (e.g., $25 or $50 depending on the charger's maximum rate) and adjust at capture. If the actual session cost exceeds the authorization, you need to handle the delta — either via a second charge or by adjusting the capture amount if the payment processor supports partial capture increase within authorization windows.
For Terminal (physical card reader), the flow is more like a traditional retail POS: the card read at session start creates an authorization hold, and the terminal sends a capture request at session end. Not all charger hardware integrates with payment terminal SDKs cleanly. Some vendors handle payment terminal integration natively; others require a separate payment device co-located with the charger and a separate integration to match payment terminal events with OCPP session events.
Membership Tiers and Subscription Pricing
Many CPOs run membership programs — a monthly subscription fee in exchange for reduced per-kWh rates or unlimited charging at certain site types. The billing integration here involves a subscription management layer (often Stripe Subscriptions or a dedicated billing platform like Zuora or Chargebee for larger networks) that needs to communicate entitlements back to the CPMS so that the session pricing engine applies the right rate when a member starts a session.
The session pricing decision happens at authorization time in OCPP — when the CPMS receives a Authorize.req and needs to respond with whether the idTag is valid and, ideally, what pricing tier applies. If the entitlement lookup adds latency to that authorization response, you create session start delays that frustrate drivers. The subscription entitlement cache in the CPMS needs to be kept in sync with subscription status changes (new subscriptions, cancellations, payment failures) with low enough latency that a driver whose subscription just lapsed doesn't get member pricing on their next session.
We're not saying membership billing is insurmountably complex. It's well-trodden territory in SaaS billing. The EV-specific complication is that the entitlement lookup has to happen in-band with the OCPP authorization flow, which introduces a latency requirement that most subscription billing platforms weren't designed to meet directly. A middleware cache that the CPMS can query locally, kept in sync asynchronously with the subscription platform, is the standard pattern.
Time-of-Use Pricing and Rate Complexity
Time-of-use pricing — where per-kWh rates vary by time of day, day of week, or season — adds another dimension to the billing calculation. The CPO's cost of energy varies with utility TOU tariffs; they often want to pass some of that variation through to session pricing. A session that starts at peak hours should cost more per kWh than the same session at off-peak hours.
The session data from OCPP is timestamped, so the TOU rate lookup is straightforward in principle: segment the MeterValues intervals by time-of-use period and apply the appropriate rate to each segment's energy. In practice, the complexity comes from meter sampling intervals. If MeterValues are sampled every 5 minutes and the TOU boundary falls within a sampling interval, you have to interpolate. For most retail use cases, this is a negligible accuracy difference. For large commercial fleet accounts where the invoice amounts are substantial, the methodology needs to be documented and consistent.
Back-Office Reconciliation: The Last Mile That Often Breaks
Getting revenue data from the CPMS into your accounting system (QuickBooks, Xero, NetSuite, or an ERP for larger operators) is often where the billing integration work stalls. The typical integration pattern is a nightly export from the CPMS of daily session revenue, which is imported into the accounting system as revenue recognition entries. This works at small scale; at network scale, the nightly batch approach creates reconciliation lag and makes same-day revenue visibility impossible.
For CPOs who want real-time or near-real-time revenue visibility in their back office, the cleaner architecture is a webhook-based integration: the CPMS pushes session completion events to the accounting system (or to an integration middleware layer) as they happen. The accounting system books the revenue immediately. Refunds and disputed transactions flow back the same way. The result is that the accounting system is the authoritative revenue record in real time, not a lagging reflection of a CPMS export.
The reconciliation gap between the CPMS session total and the payment processor settlement is worth auditing regularly regardless of integration approach. Settlement delays (typically T+1 or T+2), payment processor fees, chargebacks, and refunds all create differences between gross session revenue and net settled revenue. Building explicit reconciliation logic that accounts for these differences — rather than assuming the numbers will match — prevents accounting surprises at month-end close.
Billing integration is infrastructure that CPOs tend to under-invest in at early network scale and over-invest in complexity at larger scale. The principle that scales well: build the billing pipeline as a first-class data pipeline, not as a reporting afterthought. When session revenue data is clean, timestamped accurately, and flowing to your payment and accounting systems in near-real-time, the operational and financial reporting capabilities that build on top of it come at lower integration cost.