How a driver pays decides more about a charging network than most operators expect. It shapes the hardware you buy, what your CSMS must integrate, which regulations apply, and how many sessions fail at the start. There are four main methods in use today, and most public networks need to support at least three of them.
1. RFID cards and key fobs
The driver taps a card issued by the CPO or an eMSP; the charger reads an identifier and sends it to the CSMS for authorization. In OCPP 1.6 that identifier is the idTag in an Authorize request (up to 20 characters); in OCPP 2.0.1 it is an IdToken with a type such as ISO14443, ISO15693 or eMAID.
[2, "4f1a", "Authorize", {
"idToken": { "idToken": "04A2B91C6E5D80", "type": "ISO14443" }
}]RFID is fast, works when the phone has no signal, and is the backbone of roaming because eMSPs issue cards that work across many networks. Its weaknesses: the driver needs a card from someone in advance, and most deployments authorize on the card's UID alone, which is not a secret and can be cloned. Treat RFID as identification, not strong authentication, and set limits accordingly. Offline behaviour matters too; the OCPP 1.6 authorization post covers the local authorization list and cache.
2. Mobile apps
The driver selects a charger in an app, which has a stored payment method, and taps start. The app calls the CSMS (or, for roaming, the eMSP calls the CPO through the OCPI Commands module), and the CSMS sends a remote start to the charger: RemoteStartTransaction in 1.6 or RequestStartTransaction in 2.0.1.
[2, "9c03", "RequestStartTransaction", {
"remoteStartId": 77812,
"evseId": 1,
"idToken": { "idToken": "APP-5f2e9a", "type": "Central" }
}]Apps give the operator a direct customer relationship, receipts, notifications and pricing transparency. The friction is installation and account creation, which is exactly what a driver on a road trip does not want to do at a charger with weak mobile coverage. App-driven sessions also have more moving parts: if the charger is not connected at the moment of the remote start, the session never begins. See remote start and stop for the failure modes.
3. Ad-hoc payment: contactless terminals and web checkout
Ad-hoc payment means a driver with no prior relationship with any provider can pay on the spot. The usual implementation is a contactless EMV terminal on or near the charger, accepting bank cards and phone wallets. A lighter alternative is a QR code that opens a web checkout page.
Why it matters: it is the method that makes public charging work for everyone, including drivers who do not have your app, renters, and visitors from other countries. It is also increasingly a legal requirement (see below).
How a terminal payment works
- The driver taps a card. The terminal requests a pre-authorization for a fixed amount from the payment processor.
- On approval, the terminal or its backend tells the CSMS (or the charger directly) that the session may start, along with a reference for the payment.
- The session runs. Energy is metered as usual over OCPP.
- At the end, the CSMS calculates the final price and the payment backend captures that amount, releasing the remainder of the hold.
Integration patterns and gotchas
- Linking payment to session. OCPP 1.6 has no payment messages, so integrations use a token derived from the payment (a processor-issued reference used as the
idTag) or vendor-specificDataTransfer. OCPP 2.1 adds use cases for payment terminals; see what's new in OCPP 2.1. - Keep card data out of your CSMS. Let the terminal and processor handle card numbers and give you tokens or references. That keeps most of your platform out of PCI DSS card-data scope.
- Pre-authorization amount. Too low and long sessions exceed it; too high and drivers with debit cards see large holds. Decide what happens when the cost reaches the authorized amount: stop, or request an incremental authorization if your processor supports it.
- Capture failures. If the charger was offline at session end and the final meter value arrives late, the capture is late. Holds expire, so make sure your capture pipeline handles delayed
StopTransactionorTransactionEventmessages. - Receipts. Ad-hoc drivers have no account. Provide a receipt route (a QR code or web page keyed on the card or a session reference).
- Site terminals. A single terminal can serve several chargers, but the driver must clearly select which EVSE they are paying for.
4. Plug & Charge (ISO 15118)
With Plug & Charge, the vehicle holds a contract certificate issued under the driver's eMSP contract. When it plugs in, the car and charger run ISO 15118; the charger validates the certificate chain, and the driver's identity (an eMAID) is passed to the CSMS as the session token. No card, no app interaction. The cost is infrastructure: certificate management on chargers, a public key infrastructure arrangement covering vehicle manufacturers, CPOs and eMSPs, and OCPP messages such as Get15118EVCertificate and GetCertificateStatus. The Plug & Charge post has the full flow.
Plug & Charge is the best experience when it works, but it relies on a contract the driver already has, so it is not a substitute for ad-hoc payment.
Comparison
| Method | Needs prior account | Works for roaming | Main CSMS work |
|---|---|---|---|
| RFID | Yes (card) | Yes, via OCPI or hub tokens | Authorization, local lists, offline handling |
| App | Yes (account) | Yes, via OCPI commands | Remote start/stop, session updates to app |
| Contactless terminal | No | Not applicable (direct payment) | Payment-to-session link, capture, receipts |
| QR / web checkout | No | Not applicable | Web payment flow, remote start |
| Plug & Charge | Yes (contract in car) | Yes | Certificates, ISO 15118 relay, eMAID tokens |
Regulatory requirements
In the US, chargers funded under the NEVI program must meet 23 CFR 680.106(f): a contactless payment method accepting major debit and credit cards, plus either an automated toll-free phone number or an SMS option, and no membership requirement. Power may not be curtailed based on payment method or membership.
In the EU, AFIR requires publicly accessible recharging points to allow ad-hoc electronic payment. For new points of 50 kW and above, that means a payment card reader or a contactless device that can at least read payment cards. Below 50 kW, internet-based methods such as a QR code are also accepted. Existing points of 50 kW and above on the TEN-T road network must be retrofitted by 1 January 2027. The Commission's Q&A notes that apps requiring a contract do not satisfy the ad-hoc requirement. Our NEVI and AFIR guide goes through the software-relevant rules.
Key takeaways
- Support RFID and app for your regular and roaming customers, ad-hoc payment for everyone else, and Plug & Charge where the hardware supports it.
- Ad-hoc payment is the method most often required by regulation and the one with the most integration edge cases.
- Design the payment-to-session link and the capture pipeline for offline chargers and late messages from day one.
HashTech integrates RFID, app and contactless payments into the charging platforms we build.
