EV charger offline operation: what should buyers test before ordering?

1. Separate the functions hidden behind “works offline”

The Open Charge Alliance describes offline behavior as operation without a connection to the charging management system. Its guidance distinguishes transactions already running, authorization of new sessions and later transmission of transaction records. Cached authorization and a local authorization list are different mechanisms; their availability and configuration matter. The guidance also identifies financial risk when unknown credentials are permitted offline. These are protocol capabilities to verify on the ordered equipment, not a universal service guarantee. Source: OCA uptime guidance, section 5.3.

Ask the supplier to provide separate answers for a fleet employee using a known credential, a first-time visitor, a session already delivering energy and an operator attempting a remote action. A single “yes” in an offline-mode column does not tell your dispatch team which vehicles can leave on time.

2. Write a short service requirement before choosing a modem

Start with your operating schedule and the people you actually serve. A private depot may prioritize a controlled list of vehicles and an auditable internal energy record. A visitor site may prioritize a clear unavailable message and a way to contact support when its normal purchase flow cannot complete. These are different acceptance targets even when the charger cabinet is identical.

• Identify the expected user groups and the person responsible for adding or removing access.
• State the outage duration your business wants evaluated; ask the supplier to declare the supported storage and recovery limits rather than assuming an unlimited duration.
• List the platform, charger hardware revision, firmware revision and intended OCPP version.
• Specify which business outcome has priority: controlled access, departure readiness, recoverable billing records or public payment continuity.
• Agree who pays for the SIM, data service, platform subscription, diagnostics and any optional networking hardware.

A second connectivity path can be quoted separately, but ask how its benefit will be demonstrated. Two service contracts are not proof that a particular site has independent failure paths. Compare a measured pilot result with its recurring cost before extending it across a fleet.

3. Request evidence for six acceptance scenarios

The following is our proposed procurement worksheet. The supplier and operator should set pass/fail criteria together before a controlled demonstration. Do not unplug live equipment or interrupt customer sessions to improvise these tests.

Retain dated evidence for the exact tested combination. A video can demonstrate the customer experience; matching test references and platform records help establish what happened behind the display. Keep customer identifiers and credentials out of public demonstrations.

4. Treat payment as a separate integration

OCA's filling-station integration paper describes more than one route between a point-of-sale system and charging equipment, including a management-system path or a local controller. That architecture distinction is a reason to ask which connection your proposed payment flow relies on. It does not establish card-acquirer approval or prove a particular terminal can accept a payment without internet. Source: OCA payment integration overview.

Put the terminal supplier, payment provider and charging platform operator in the same scope discussion. Ask each party to name the record it produces, the failure it reports and the support team that handles a disagreement. Do not describe delayed upload of a charging record as successful collection of money.

Use the payment-readiness planning tool to organize these questions. It is a preliminary checklist, not payment-network certification or permission to process transactions.

5. Check optional features, not just the protocol label

OCA's OCPP 2.0.1 certification page identifies a mandatory Core profile while listing optional functionality, including local authorization list management. Request the implementation's declared feature scope and applicable certificate details. Do not infer every optional function from the words “OCPP compatible.” Source: OCA certification scope.

Ask for the ordered model and firmware to appear on the acceptance record. If a controller, modem or platform is substituted, require the supplier to explain which evidence remains applicable. For broader handover planning, use our FAT and SAT checklist.

6. Compare the cost of an accepted operating system

Build a comparison with separate rows for hardware, optional connectivity, recurring platform charges, integration testing, commissioning, training and local support. Mark each item as included, optional or supplied by another party. A low cabinet price is difficult to compare with a quote that also includes the operating workflow.

For a pilot, record the number of attempted sessions and their outcomes, not only whether the dashboard reports a connected station. Keep unresolved cases visible. Agree a review point before ordering the next batch; this creates a practical purchasing decision without inventing a guaranteed savings percentage or uptime promise.

If site power is also a constraint, treat it as a separate workstream using the site-power planning tool. Offline communications features do not supply backup electricity or replace a qualified assessment of the site's electrical installation.

Related procurement guides

• OCPP integration questions
• Fault evidence before a reset
• Build a structured RFQ brief

Primary sources reviewed 7 September 2026. Our worksheet is a buyer-planning proposal, not an OCA test specification or a claim of certification. Final technical, safety, privacy and local compliance requirements need project-specific qualified review.