PCI DSS And EV Charging: What Card Payments At The Charger Scope In

Card Payments At The EV Charger

When a charge point operator adds a card reader to a public EV charger, it solves one problem — ad-hoc payment without an app — and inherits another. That card reader brings the site into PCI DSS scope, the payment-card industry’s data security standard that governs how card account data is stored, processed and transmitted. The practical question is not whether you are in scope (you are, the moment card data touches any part of the charger or its network) but how much of the standard you actually have to satisfy.

This post covers the compliance layer that sits underneath card-present payment at the charger. For the driver-facing payment menu — QR, wallets, RFID — see Making Payments Effortless. For back-office PSP reconciliation and settlement, see Wiring Charging Revenue Into Your Finance Stack. For OT cybersecurity at the charging site, see IEC 62443 For EV Charging. This post owns the PCI DSS scope question: what triggers it, which self-assessment questionnaire a CPO faces, and how the right terminal keeps most of the standard out of your environment.

How Card-Present Payment Brings A CPO Into PCI DSS Scope

PCI DSS v4.0.1, published by the PCI Security Standards Council in June 2024, is the current version of the standard. Its 51 formerly future-dated requirements all became mandatory on 31 March 2025, so the full standard is now in force with no transition grace period remaining. The moment a charger accepts a card tap — credit, debit or prepaid — the CPO becomes a “merchant” in PCI terminology and the standard applies.

How much of it applies depends entirely on one architectural choice: where card data is decrypted.

The P2PE path — small scope

A PCI-validated Point-to-Point Encryption (P2PE) terminal encrypts card data at the point of interaction — inside the card reader itself — and transmits it in encrypted form directly to the payment processor. The card data never enters the CPO’s backend, network or any system the CPO controls. In PCI terms, those systems are “out of scope.”

An operator using a validated P2PE solution completes SAQ P2PE, the shortest in-person self-assessment questionnaire. SAQ P2PE covers roughly 33 requirements — principally physical security of the terminal, personnel awareness and vendor management — because the encryption solution has already satisfied the data-protection controls on the CPO’s behalf.

The critical eligibility requirement: the terminal must appear on the PCI Council’s list of Validated P2PE Solutions. An EMV-capable terminal that encrypts card data but is not PCI-validated as a P2PE solution does not qualify — the operator falls back to a longer SAQ (typically SAQ B-IP or SAQ C) depending on how the terminal connects to the processor. The validation status of the specific terminal model is the dividing line.

The home-built path — large scope

If the CPO builds its own card-acceptance path — connecting an unvalidated reader, routing card data through its middleware, or storing card numbers for reconciliation — it faces SAQ D-Merchant, the most comprehensive questionnaire, covering over 300 individual requirements. That includes network segmentation, encryption at rest and in transit, access controls, logging, vulnerability management, penetration testing and an annual attestation of compliance.

The single practical instruction this section exists to deliver: do not build card acceptance yourself. Use a PCI-listed P2PE terminal from your acquirer’s approved list and the entire card-data environment stays inside that terminal. Your payment and billing platform handles session pricing, invoicing and settlement — none of which requires touching raw card data.

Why Card Acceptance Is Becoming Mandatory

For years, most charging networks relied on proprietary apps — download, register, link a payment method, then charge. That worked when EV drivers were early adopters willing to install a different app for every network. It does not work for the ad-hoc driver pulling into a station for the first time, and regulators in multiple markets have now moved to mandate alternatives.

Europe — AFIR’s card-reader mandate

The Alternative Fuels Infrastructure Regulation (EU 2023/1804) requires that every publicly accessible fast charger of 50 kW or more on the TEN-T network must accept card-based payment — credit or debit, via a payment card reader or contactless device — from April 2024 for new installations and by 1 January 2027 for existing infrastructure. A QR-code-only payment flow does not satisfy the requirement for these chargers. Below 50 kW, a “secure ad hoc payment process” — which may include QR-based flows — is sufficient. For the full AFIR context and what else it requires of CPOs, see AFIR And Its Relevance To EV Charging In Europe rather than repeating it here.

United Kingdom — contactless by regulation

The Public Charge Point Regulations 2023 (S.I. 2023/1168) require contactless card payment — without a pre-existing contract or app — on all new public charge points of 8 kW and above deployed from November 2024. The penalty for non-compliance is up to GBP 10,000 per charge point, enforced by the Office for Product Safety and Standards. Operators above the micro-business threshold cannot rely on app-only payment in the UK market.

India — UPI sidesteps the card question

India’s public charging ecosystem has largely bypassed physical card readers altogether. UPI-based QR payment and UBC (Unified Bharat eCharge) allow ad-hoc payment without an app download, and no card data touches the charger or the CPO’s systems. Operators using white-label EV charging apps already offer in-app UPI payment natively. This means a CPO operating exclusively in India faces no PCI DSS card-present scope at all. But a CPO selling its platform into Europe or the UK cannot rely on this — the platform must support card terminals alongside UPI and wallet-based flows.

Terminal Choices And What Each Costs To Run

Every terminal form factor brings a different cost, failure mode and compliance footprint. The choice shapes both the driver experience and the CPO’s PCI DSS obligations.

Integrated card reader

Built into the charger by the hardware OEM. Lowest vandalism risk — no separate device to damage or steal — and a single hardware maintenance contract. The reader is where the driver already stands, so the interaction is seamless. The trade-off: you are typically locked to the payment processor the OEM has certified for that reader, and replacing or upgrading the reader may require a charger firmware update or a physical swap.

Standalone POS terminal

A separate EMV-certified terminal mounted beside or on the charger. More flexibility — you can switch payment processors without replacing the charger, and the terminal’s software updates independently. The cost: a second device on site that can fail, disconnect or be vandalised. Each terminal needs its own power supply, SIM or network connection and maintenance schedule. For a network of hundreds of chargers, that is hundreds of additional points of failure.

QR and UPI-only — no physical reader

Zero hardware cost, zero PCI card-data scope and the fastest deployment path. The driver scans a QR code and pays via UPI, a banking app or a payment link. This satisfies India’s market and AFIR’s below-50-kW “secure ad hoc” requirement, but it does not satisfy the card-reader mandate for 50 kW+ chargers in Europe or the UK’s contactless rule. In markets where regulations require a card reader, QR-only is not enough on its own.

Soft POS

The operator’s own device — phone or tablet — acts as a contactless terminal using NFC and a PCI-certified payment application. Potentially useful at staffed, low-power destination sites. Impractical for unattended 24/7 DC fast chargers. The device must be on the PCI Council’s list of validated Contactless Payments on COTS (CPoC) or Software-Based PIN on COTS (SPoC) solutions.

Whichever path you choose, a card reader is one more thing on the site that can go offline. Factor in the connectivity requirement (dedicated SIM versus shared network), the mean time to repair and whether the charger continues to accept sessions via app or RFID when the reader is down. A terminal outage should degrade payment options, not prevent charging entirely.

Pre-Authorisation On An Open-Ended Charging Session

An EV charging session is an open-ended transaction — neither the energy delivered nor the duration is known when the driver taps a card. This requires a pre-authorisation flow that most retail and hospitality merchants never encounter.

The standard pattern: the terminal places a hold (pre-authorisation) on the driver’s card for an estimated amount — typically between EUR 25 and EUR 100 depending on charger power and operator policy. The session runs. When it ends, a charging management platform like YoCharge sends a capture request for the actual amount consumed. The payment processor releases the unused portion of the hold.

What the platform must expose to make this work cleanly:

• A configurable hold amount per charger or site, reflecting realistic session cost at that power level
• A capture trigger tied to the session-end event from the charger (the OCPP StopTransaction message)
• Partial reversal capability if the session delivers less energy than the hold covers
• A refund path for failed sessions — when the charger faults mid-session or the session starts but delivers zero energy, the hold must be released, not captured

If the session cost exceeds the hold, the operator must either perform an incremental authorisation or absorb the difference. Some operators address this by setting holds conservatively high, which creates driver complaints — a driver who sees a GBP 100 hold on a GBP 12 session, and then waits five days for the release, will leave a one-star review. The hold amount is a policy decision that balances fraud risk against driver experience, and getting it wrong costs both money and reputation.

For the accounting and settlement side of this flow — how PSP reconciliation aligns with energy-metered billing — see EV Charging Billing Integration rather than re-deriving it here.

The Roadmap That Shrinks The Card Surface

Plug and Charge under ISO 15118 and Autocharge move authentication off the card entirely — the vehicle itself becomes the credential, authenticated at the protocol level before any payment instrument is involved. As these protocols gain adoption across more charger hardware and vehicle models, card acceptance at the charger becomes a fallback rather than the primary path. For the ISO 15118-2 versus ISO 15118-20 upgrade path and what each delivers, see the Plug and Charge Roadmap. Until that adoption curve catches up, a PCI-listed P2PE terminal remains the simplest way to accept cards at the charger while keeping the compliance surface as small as the standard allows.

Frequently Asked Questions

Sources: PCI Security Standards Council — PCI DSS v4.0.1 | UK Legislation — The Public Charge Point Regulations 2023 (S.I. 2023/1168) | European Commission — AFIR (EU 2023/1804) | EMVCo — EMV Specifications