Xiaochong Energy

NETWORK ACCESS · ENGLISH BUYER GUIDE

EV charging roaming: a map pin is not a completed customer journey

By Xiaochong Energy · · 7 min read

A public charging operator may buy connected hardware, see the station online and still discover that a customer's usual charging app cannot start a session. The missing work can sit between organisations rather than inside the charger. Before ordering a roaming-enabled project, define which customers should gain access, which partners will serve them and what evidence proves the whole journey works.

Xiaochong DC charger example; roaming availability requires separate project integration and acceptance

This guide is a procurement framework, not a promise of Xiaochong roaming-network membership, legal advice or approval to modify a live charging system. Model, firmware, backend, partner agreement, payment scope and local requirements need project-specific confirmation.

1. Separate the charger connection from the roaming relationship

Open Charge Alliance defines OCPP as communication between charging stations and their management systems. The official OCPI introduction describes a different boundary: exchanges between charge point operators and e-mobility service providers, including authorization, station information and charging records. These are complementary roles, not interchangeable labels.

For the purchase brief, draw the chain in plain language: charger, charging management provider, any roaming intermediary, the selected customer-facing service, and the parties responsible for billing. Put an organisation and an accountable contact beside each boundary. If one company performs several roles, keep those responsibilities distinguishable in the offer.

Ask a supplier claiming “roaming ready” to state exactly what is ready today. Is it an available backend interface, an existing commercial relationship, a completed test for your configuration, or a future integration option? Record unresolved items as dependencies. An OCPP checkbox should not silently become a promise that every charging card, app or country is supported.

2. Choose a launch partner list, not an unlimited coverage claim

Start with the intended users: fleet drivers with an employer account, visitors using a particular service, or customers at destination parking. Ask those customers which access route matters before buying integrations. The useful deliverable is a named initial partner list with the required countries, accounts and connector configurations, not a large network number without a usable path.

For each partner, confirm commercial onboarding, technical ownership, permitted station locations and who authorizes public launch. Request the protocol version, implemented scope, test environment and acceptance evidence from the backend or roaming provider. Where a provider proposes an intermediary, ask which responsibilities remain with the operator and which depend on another contract.

Keep direct walk-up payment separate from account-based roaming. A self-service terminal, a website payment page and a partner's app may use different authentication, support and billing paths. Passing one does not accept the others. List required paths independently in the quotation and test plan.

3. Verify what the customer sees before they arrive

Build a short station-data sheet from the actual installed configuration: location, entry route, public opening hours, access restrictions, connector identification and the advertised service. Assign an owner for updates. A technically reachable station behind a closed gate is not the same customer experience as an unrestricted public station.

Acceptance checkpointEvidence to request from the launch partner
Find the correct stationVisible location and entry information matched to the actual site, not just a nearby street address.
Select the correct connectorCustomer-facing identifiers matched to the installed equipment and backend records.
Understand access and priceAgreed presentation of restrictions and applicable price information for the selected account and path.
Recognize a service changeA documented method and owner for updating availability, operating hours and withdrawn equipment.

Ask how quickly approved changes are expected to appear and how stale information is identified. Do not invent a universal update deadline. Keep dated evidence from the agreed test environment and, when authorized, the production partner interface. A screenshot is useful evidence of presentation, but not proof of successful authorization or charging.

4. Run one traceable journey per launch path

Agree an authorized pilot with the technical and operations teams. Follow a permitted test customer from locating the station to selecting the connector, requesting access, starting a charging session, ending it and obtaining the agreed record. Capture timestamps and the identifiers needed to join the records across systems. Avoid using real customer personal data where approved test accounts will suffice.

Make the expected outcome explicit at each handoff. An app acknowledging a request is not evidence that energy was delivered. Similarly, a session visible in the operator dashboard does not show whether the customer's chosen service received the outcome. Ask the responsible parties to demonstrate both sides, and document any untested branch before launch.

Include controlled exception scenarios in the provider's approved test environment: an unauthorized account, an unavailable connector, a delayed response and an interrupted session record. Define the expected customer message and support owner. Do not induce electrical faults, disable protections, expose credentials or experiment on customers' active sessions.

5. Keep record exchange separate from settlement

The OCPI CDR module describes a Charge Detail Record for a concluded session, exchanged from the charge point operator to the relevant service provider. It also defines credit records instead of changing an already-sent CDR, and leaves some commercial timing to agreements between parties. This is a data-exchange framework, not proof that an operator's bank account has received money.

Ask your providers for a reconciliation example using approved test data: the completed session, applicable price basis, exchanged record, acceptance or rejection, and the commercial document or payment evidence required by your agreement. Identify responsibility for missing records, duplicates, disputed charges and corrections. Do not assume the customer's retail price is identical to the amount payable to the station operator.

Compare onboarding, recurring platform, transaction, intermediary and support charges on the same stated assumptions. Request written treatment of taxes, currency, settlement periods and disputes from the responsible commercial parties; obtain qualified local review where necessary. This checklist does not prescribe rates, tax treatment or expected income.

6. Launch in stages and retain an exit record

Accept a defined initial scope before announcing wider compatibility. Record the equipment model, firmware, management platform, partner, configuration baseline, test date and unresolved limitations. Repeat the relevant acceptance checks when a change can affect that path. Avoid advertising a partner logo or network availability without permission and current evidence.

Keep an owner-accessible partner register with escalation contacts, update responsibility and the agreed method for removing a retired station. Before changing management provider, confirm which connections and records can transfer and which relationships require new onboarding. Our backend exit-readiness guide covers the wider handover.

Use the free RFQ brief builder to capture the project baseline, then attach the launch-partner and acceptance matrix. The tool does not establish roaming agreements, certify interoperability or approve payment arrangements. The cost-control opportunity is to expose missing scope before ordering, not to assume a guaranteed saving.

Buyer FAQ

Does an OCPP connection prove that partner charging apps will work?

No. OCPP station-to-management connectivity is only one part of the project. Confirm the roaming partners, commercial permission, backend interface and tested customer journey separately.

Is a station appearing on a map enough for roaming acceptance?

No. Verify the correct connector, access conditions, authorization path, completed charging session and agreed records with each launch partner.

Does receipt of a Charge Detail Record prove payment was received?

No. Record delivery and commercial settlement are separate checks. Agree reconciliation, dispute ownership and payment evidence with the responsible parties.

Discuss equipment and project integration with Xiaochong

Xiaochong Energy Technology (Zhongshan) Co., Ltd., China supplies commercial AC and DC charging equipment with integration options confirmed by project. Send your country, site type, required charging paths, proposed backend and launch-partner list. Ask for the exact supported configuration and responsibility split; this article does not claim universal OCPI support or an existing agreement with your selected roaming provider.

For local assembly, distinguish AC EV charger SKD kits and technical documentation from DC EV charger SKD kits and technical documentation. Discuss component scope, production and assembly support, professional repair and maintenance skills, and available training videos for the chosen track. Free technical documentation is available on request. Confirm model, document revision, required language, permitted use, training, testing and support scope. Hardware, unrestricted software/IP, certification and every training or repair service are not automatically free.

See the official partner program, AC/DC SKD scope and procurement guide.

xc0225888@163.com · Sales 1: +86 137 1772 6888 · Sales 2: +86 134 2580 6997

Primary protocol sources reviewed 18 September 2026. The procurement workflow is editorial guidance, not a protocol certification test or a market-specific compliance determination. Referenced organisations do not endorse Xiaochong.