EV Charging Payment Kiosk Hardware Spec: Tender Checklist

A payment kiosk rarely fails tender acceptance because a certificate is missing. It fails because the certificate covers the wrong chain — an enclosure report that was tested without glands, a PCI PTS approval for a terminal model the bidder swapped in Q3, an “OCPP 2.0.1 compliant” line with no firmware version behind it. This checklist gives you nine clauses to write into the RFQ, the verification step to run on the sample unit, and the document each clause must be backed by before you shortlist.

The nine clauses, in the order they usually bite:

1. Enclosure IP/IK, with the test condition written in
2. Sunlight-readable display, with the thermal design behind it
3. Payment path — EMV contactless, QR, PIN pad and PCI PTS scope
4. Cash acceptance and recycling, only if site economics justify it
5. OCPP and OCPI, versioned and testable
6. Connectivity redundancy and offline authorization
7. Power, surge protection and heater/condensation control
8. Operating temperature range with the display and payment module active
9. Modularity, MTTR and spare-parts availability

First: your tender has four separate certification chains, not one

Most bid matrices collapse compliance into a single “CE / certified” column. That column hides four independent chains, each with a different certificate holder and a different failure mode:

• EVSE side. Safety and functional testing against IEC 61851, UL 2202 or UL 2594, plus EMC to IEC 61851-21-2. DEKRA publishes this scope for EV supply equipment testing, alongside interoperability and conformance work covering OCPP and ISO 15118 ( DEKRA EV charging infrastructure testing ) — confirm the current scope on the source page at time of reading, and note that a lab’s published scope is not evidence that your specific model was tested.
• Payment side. EMVCo contactless Level 1 for the reader, PCI PTS approval for the terminal model and firmware, and PCI DSS for the gateway and data environment. Three documents, three holders.
• Enclosure. IEC 60529 for IP and IEC 62262 for IK, reported against the exact model and the as-tested mounting configuration.
• Protocol and software. OCPP 1.6J or 2.0.1 conformance plus OCPI for roaming — with the certification body and firmware branch named.

A CE mark on a line item covers none of chains two to four. A supplier “compliance statement” letter is not a substitute for a certificate whose holder name matches the legal entity you are signing with.

Clause 1 — Enclosure IP/IK: write the test condition, never just the number

What to write. Specify IP54 versus IP65 by mounting position and orientation, and state explicitly whether cable glands, cable entries and the service door are included in the tested configuration. IP ratings under IEC 60529 are defined for a stated mounting arrangement and do not automatically include glands unless the report says so — a kiosk whose gland plate was sealed for the lab and left open for the installer is an IP54 product wearing an IP65 badge.

Add corrosion as a separate clause. IP says nothing about salt spray. For Gulf coastal and de-icing-belt sites, write the salt-spray duration and the substrate/finish system (for example galvanised steel with a specified powder-coat build) as its own line, because an unsealed gland plate in coastal humidity is a recognizable field failure and no IP number predicts it.

For vandal exposure in forecourts and parking garages, IK10 corresponds to 20 J impact per IEC 62262. IK08 is common in the market — if you accept it, accept it as an explicit, priced downgrade on the matrix, not as a discovery at delivery.

How to verify. Open the sample unit, photograph the gland plate and door seal as shipped, and compare against the photographs in the IP report.

Proof document. The IP/IK test report page showing model number, mounting configuration and test date — not the marketing badge on the datasheet.

Clause 2 — Sunlight-readable display: nits, contrast and the thermal trap behind the glass

What to write. Require a measured luminance figure at a stated condition (nits at a defined ambient and measurement point) plus the anti-glare or optical-bonding treatment. A bare nits number without measurement conditions cannot be compared between bidders. On direct-sun Gulf forecourts, a panel rated in the low hundreds of nits becomes unreadable at midday; the figure that matters is contrast under incident sunlight, not peak luminance in a dark room.

The second half of this clause is thermal. A high-brightness panel in direct sun adds heat load inside a sealed enclosure. Require the supplier’s thermal design statement and any brightness or performance derating above a stated ambient temperature. Without it, you are buying a display that meets spec in the lab and dims in service.

Also specify the touch technology and its behaviour with gloves and wet fingers. Indoor-retail PCAP panels get substituted into outdoor units routinely. Published kiosk sheets do name panel and touch type precisely — one public example lists a 7.0″ 1024×600 TFT with PCAP touch ( Virta payment kiosk specification ) — use that level of specificity as the benchmark for what every bidder must disclose. Note also that capacitive touch layers are known to lag or misread at −20 °C, so ask for the low-temperature touch response, not just the storage rating.

Proof document. A site-condition readability demonstration on the sample unit outdoors at midday, plus the panel datasheet naming model and touch type.

Clause 3 — Payment path: EMV contactless, QR, PIN pad and the PCI PTS scope trap

What to write. Split this into three separate requirements: contactless EMV acceptance with the card scheme list; the QR or ad-hoc payment route; and a PIN pad with PCI PTS approval if card-present PIN is in scope for your markets.

Write a PSP compatibility clause. AMPECO’s practical guide flags that terminal hardware must be compatible with your chosen Payment Service Provider, which adds a verification step and can limit your terminal shortlist ( AMPECO, Payment Terminals for EV Charging ). Verify compatibility with your PSP directly and in writing before award; this is where shortlists quietly lose a bidder.

The scope trap: PCI PTS approves a specific terminal model at a specific firmware version. It does not approve “the kiosk.” A firmware update can move the unit off the approved version, so require a change-notice clause — no firmware release to your fleet without re-confirmation of the PTS approval status. Separately, PCI DSS governs the payment data environment and gateway, and is an operator-side obligation as much as a supplier’s.

If you are writing an EU tender, get the regulatory scope right. AMPECO’s guide states that AFIR’s payment terminal requirement targets DC fast chargers above 50 kW, and that AC chargers can satisfy ad hoc payment through alternative methods such as a QR code linking to a web payment flow without a physical terminal. Treat this as a secondary source and verify against the regulation text and your national transposition before you write it into a clause — a wrongly scoped terminal requirement inflates the bill of quantities for no compliance benefit.

Proof document. PCI PTS approval listing showing the terminal model and approved firmware version, with the certificate holder named, plus a written PSP compatibility confirmation.

Clause 4 — Cash acceptance and recycling: only if your site economics need it

What to write. Specify note/coin acceptance separately from recycling. Acceptance is a payment feature; recycling is a cost driver and a field-service burden with its own jam profile. Require cash-box capacity expressed in note count at a stated note mix, the jam-clearing procedure, the time to clear, and whether the cash module carries its own certified status.

State the reconciliation workflow: shift-level or cassette-level reporting, and whether it integrates with your CPMS or settles standalone. Parking garages and markets with a high cash share justify the module; a card-dominant forecourt in a cashless-leaning market usually does not.

Proof document. Module-level spec sheet with the note mix stated, plus a jam-and-recovery demonstration on the sample unit against an agreed time limit.

Clause 5 — OCPP and OCPI: what “2.0.1 compliant” has to be backed by

What to write. Name the version and profile (1.6J or 2.0.1), the testing or certification evidence, and the firmware branch the device ships on. Specify OCPI only if roaming is in scope in year one — otherwise it is an unused integration line item on the invoice.

Then convert “supports OCPP” into a testable deliverable: a message log demonstrating start/stop transaction, meter values and error handling against your own CPMS.

How to verify. Run the integration test in a staging environment before shipment release. Not after delivery, not on site.

Proof document. OCPP conformance evidence naming the certification body and version, plus your signed integration test record.

Clause 6 — Connectivity redundancy and offline authorization

What to write. Require at least two independent uplinks — for example Ethernet RJ-45 plus cellular — with automatic failover and the failover time stated. Published kiosk sheets commonly list “4G or Ethernet LAN RJ-45” as a connectivity option (Virta’s sheet is one example), so the redundancy clause is what separates bidders, not the presence of a radio.

Define offline behaviour explicitly: local whitelist, stored-and-forward transactions, maximum offline transaction value, and what the driver sees on screen when the backend is unreachable. Then clarify SIM and data ownership and who pays — a recurring opex line that is routinely missed in evaluation and surfaces in year two.

Proof document. A deliberate network-disconnection test on the sample unit, with the screen sequence and transaction log captured.

Clause 7 — Power, surge and the heater clause everyone forgets

What to write. Specify voltage and frequency per market — 230 VAC 50 Hz in EU and Gulf deployments versus 120 V in the US — and note that dual-variant hardware changes the certification scope, so a single global SKU is a claim to verify, not assume.

Require quiescent and peak consumption, and consumption with the heater active. Public spec sheets do quantify this: one lists approximately 40 W operating with the heater at 90 VA (Virta, cited above). Use that granularity as the disclosure benchmark for every bidder. Then add the surge protection level and earthing requirement per site, plus the heater and condensation-control strategy for cold and humid climates — a heated enclosure is what prevents the condensation short you would otherwise discover after the first winter.

Proof document. Power and thermal design statement, plus the surge-protection component rating on the bill of materials.

Clause 8 — Operating temperature and thermal architecture

What to write. Specify the operating range with the display and payment module active . A kiosk that “works to 55 °C” with the screen dimmed or the terminal throttled is a different product from the one in the tender. Ask whether cooling is fanless or filtered-fan, and how the filter is serviced — a filtered fan in a dusty parking garage becomes a scheduled maintenance item you did not budget.

Require the derating statement above the rated maximum ambient, and confirm whether direct-sun installation sits inside or outside the rating.

Proof document. Thermal test summary stating the configuration tested (display on, payment module active, sun load or ambient) and the derating curve.

Clause 9 — Modularity, MTTR and the spare-parts clause

What to write. Require a field-replaceable unit list with per-module removal time, and turn MTTR into a contractual number rather than an adjective: which module, which tool, how many minutes, by what technician grade. Specify spare-parts availability in years after end of production and the price basis for the top five failure modules.

Align the service model with how many charge points one kiosk serves. AMPECO notes that in the integrated approach one payment terminal is usually limited to one charger, which can raise total cost of ownership for charge point operators, and that a shared-terminal kiosk model also exists (AMPECO, cited above). A kiosk serving multiple chargers changes the economics of both the hardware line and the service contract.

Be honest about the limit: no supplier-side field MTTR statistics are published here, and no third-party long-term corrosion study is cited in this article. Any bidder quoting a field MTTR figure should be asked for its source, sample population and measurement definition — so you can decide whether it applies to your climate and your technician coverage.

What document proves which clause

Acceptance test checklist: run this on the sample unit before the PO

1. Rain/wash-down test on the as-shipped mounting configuration, glands fitted and door closed; photograph the interior immediately afterwards.
2. Midday readability test at full brightness, with an internal temperature reading after two hours of sun exposure.
3. Payment matrix: contactless EMV, QR flow, PIN pad if in scope, and one deliberate network failure to observe offline behaviour.
4. Cash module cycle test if applicable, with a timed jam recovery.
5. Certificate-to-unit match: the model number on each certificate matches the unit shipped, and the firmware version matches the PCI PTS approval.
6. Document pack handover: IP/IK reports, EMC and EVSE test scope, OCPP conformance evidence, PCI PTS approval, spare-parts price list.

What to put in the RFQ pack — and what to refuse

Refuse unaudited “compliance statements.” Accept only documents that name the certificate holder, the model and a validity date, and require bidders to flag gaps honestly: a supplier that tells you which clauses it cannot evidence is lower risk than one that returns an all-green matrix. Convert every unchecked clause into a warranty term or an acceptance holdback rather than assuming it after the PO is signed.

What we can evidence on request: test reports, certificate holder names and model-number matching for the enclosure and payment modules we supply. What we cannot: published field MTTR statistics or third-party long-term corrosion studies. Ask for those only from parties that can produce the underlying data.

Short answers to the questions that come up in every tender review

Does an EV charging payment kiosk need AFIR certification? There is no such certificate. AFIR sets a payment requirement; scope depends on charger type and power. Per AMPECO’s guide, the terminal requirement targets DC fast chargers above 50 kW, while AC ad hoc payment can be met by a QR-to-web flow — verify against the regulation text and your national implementation.

Is IP65 enough for an outdoor payment terminal? Only if the report covers your mounting orientation and includes glands, cable entries and the service door. Add a separate corrosion clause; IP does not describe salt-spray performance.

Does PCI PTS approval cover the whole kiosk? No. It covers the approved terminal model at an approved firmware version. Enclosure, display, connectivity and the gateway’s PCI DSS scope sit outside it.

Should a 2026 rollout specify OCPP 1.6J or 2.0.1? Specify whichever version your CPMS and roaming partners actually run in year one, name the certification evidence, and pin the firmware branch. A version number without a conformance record is a marketing line.

Can one payment kiosk serve multiple chargers? Yes — shared-terminal kiosk models exist, and AMPECO notes the integrated one-terminal-per-charger approach can raise total cost of ownership. Make the ratio explicit in the tender so bidders price the same architecture you are evaluating.

Next step

Request the 2026 EV charging / parking kiosk spec sheet, test reports and a sample unit quote — specify your enclosure rating, display brightness target, payment module mix (contactless, QR, PIN pad, cash recycling) and mounting configuration, and we will return the clause-by-clause response together with the documents behind each one, so your acceptance matrix is filled from evidence rather than from a compliance letter.