Payment Migration for EV Charging Networks: What Gets Missed

Payment migration is not moving a card-on-file table from one database to another. It is carrying over seven distinct surfaces, each with its own failure modes, each able to break without the others noticing.

Treating payment migration as a single checkbox is how six of these seven get skipped. Each one skipped is a place revenue or compliance can leak.

• Authorization: confirms a payment method is valid and holds funds before a session starts.
• Tariff: turns kWh, time, and session rules into a price.
• Tax: applies GST, VAT, or sales tax for the jurisdiction.
• Receipt: produces a document that is accurate and compliant.
• Wallet: stored balances, prepaid credit, autopay mandates.
• Roaming: sessions that settle across networks via OCPI.
• Settlement: moves money to the right merchant and reconciles it against sessions.

Not everything in a wallet migrates the same way, and assuming it does is where stored-value problems begin. Sort it into three buckets:

The safe assumption: stored payment state is not portable until proven portable, token by token and mandate by mandate. Autopay in particular needs an explicit test after cutover, not a hopeful glance.

• Carries over cleanly: the tokenized card reference, the PSP’s stored token standing in for the real card number. If the target uses the same PSP and the tokens are portable, these move without re-prompting the driver.
• Needs re-authorization: anything scoped more tightly than a raw token. Cards enrolled with 3DS are often scoped to the merchant that authenticated them, so moving platforms can require the driver to re-authenticate. Expired or transferred PSP mandates land here too.
• Expires silently: the dangerous one. Autopay mandates tied to a specific PSP merchant ID do not always error when the merchant changes. They just stop pulling funds, and the first sign is a wallet that never tops up and a session that declines weeks later.

Two platforms can hold the same tariff on paper and price the same session differently, because the rules around the edges are implemented differently.

What makes tariff drift dangerous is that it breaks silently. The session completes, the receipt looks reasonable, nothing flags an error. The discrepancy only appears when someone reconciles expected revenue against collected revenue and the numbers do not meet. Test tariff parity with real session shapes across the boundaries; do not assume it from a matching rate card.

• Time-of-day windows: when a rate changes at midnight, does that minute belong to the closing day or the opening one? Two systems can disagree, and a session straddling the boundary gets priced two ways.
• Ramping schedules: a rate that steps up with power or duration can be linear on one platform and stepped on another. The driver’s total moves depending on which model the new CMS uses.
• Minimum-session fees: applied at start, at end, or once per session. The outcome, and what the driver pays for a short stop, differs.

Receipts are where a migration can manufacture a compliance problem without anyone noticing. Every jurisdiction has required lines:

When the target CMS’s receipt template does not include a line the tax authority expects, the platform does not throw an error. It just issues receipts that are missing something, and keeps issuing them.

The damage compounds because nobody notices immediately. Drivers rarely scrutinize an EV receipt, and the CMS considers its job done once the document renders. Weeks of sessions can pass before a finance review or an audit catches it, and fixing it retroactively is painful: reissuing corrected receipts across a back catalogue, reconciling collected against documented, and explaining the gap to a tax authority that expected the line the first time.

The check is simple and belongs before cutover: take a real receipt from the target CMS for each jurisdiction you operate in, put it next to the local requirement, and confirm every mandatory line is present and correct.

• India: a GST breakdown
• EU: a VAT number and rate
• US: a sales-tax line in the relevant states

Roaming turns a clean cutover into an overlap problem, because during the migration window the old and new networks can both think they own a session.

Handle roaming as its own cutover step. Agree which platform owns roaming sessions during the window, make sure only one issues CDRs for a given session, and confirm settlement is addressed to a single merchant identity before partner-network drivers start arriving. Roaming handled as an afterthought is roaming that double-bills.

• Duplicate charge risk: if a charger is visible to eMSP partners through both platforms at once, a roaming session can be recorded twice.
• Misrouted settlement: eMSP settlement is addressed to a merchant identity. If the incoming and outgoing platforms present different identities during the window, money can settle to the wrong place or not at all.
• Double CDRs: OCPI Session and CDR records (the Charge Detail Records settlement is built on) can be issued from both platforms for the same physical session, leaving partners to work out which is authoritative.

Every wave should pass one end-to-end payment test before it is called done, run with real payment methods across at least three PSPs (a path that works on one processor can fail on another).

Run the full chain in order, with a concrete pass/fail at each step:

A wave that passes this matrix on real methods across multiple PSPs is a wave you can trust with revenue. One that passed only a free test kWh is a wave you will hear about in reconciliation. If you want this validation built into your migration waves, that is part of our EV charger CMS migration process.

• Authorize: funds held and released correctly.
• Charge: session delivers and closes.
• Tariff: price matches the expected rate for that session shape, including boundary cases.
• Tax: correct jurisdiction line at the correct rate (GST / VAT / sales tax).
• Receipt: every mandatory line present.
• Wallet: debit posts, and for autopay the mandate actually pulls.
• Settlement: money reconciles against the session that earned it, with no duplicate from a roaming overlap.