EV Charger Payment Systems: Terminals, Backends and Roaming

A payment system is more than a card reader. Authorization, pricing, roaming, settlement, receipts, and vehicle identity have to work as one chain.

Drivers judge a charging site by the first and last minute: whether the session starts, whether the price is clear, and whether payment works. Behind that experience is a chain of charger hardware, payment terminals, backend software, roaming platforms, and financial settlement. A weak link anywhere in the chain creates support tickets even when the charger itself is healthy.

Payment design also affects site operations. The operator needs authorization, metering, pricing, tax handling, refunds, settlement, and reporting. The driver needs a simple way to pay and a receipt. Both depend on the same data flowing correctly from the charger meter to the backend.

The Main Payment Methods at a Public Charger

Most public charging sites use one or more of four methods. A card terminal accepts contactless bank cards and mobile wallets. A QR code opens a web or mobile payment flow. A mobile app authenticates the driver through an account. Plug and Charge uses the vehicle identity and a certificate chain to start the session automatically.

The method should match the audience. Local drivers may prefer an app, while visitors and fleet drivers need a payment option that does not require downloading software. A site with no card terminal can lose revenue from occasional users even if its app experience is excellent.

The charger should publish price information before authorization whenever possible. Regulations in some markets require a clear display of price per kWh, time-based fees, and idle fees. The EU Alternative Fuels Infrastructure Regulation is one example of a framework that affects public charging payment and pricing transparency.

How a Payment Session Moves Through the System

A typical session begins when the charger reads or receives an identity. The identity may be a bank card token, a roaming identifier, an app account, or a Plug and Charge certificate. The charger sends an authorization request through the backend or payment terminal. Once approved, the charger starts the session and records energy and time.

At the end of the session, the charger sends a meter stop value and a reason for termination. The backend calculates the price from the tariff, applies taxes and discounts, and initiates capture or settlement. The payment provider returns a result, and the driver receives a receipt or an app record.

• Authorization identifies the payer and confirms that the payment method can be accepted
• Metering provides the energy and time data used for the final price
• Pricing maps the session to a tariff, including taxes, parking, and idle fees
• Settlement transfers funds and reconciles them with the operator account
• Receipts and support records explain the charge if the driver disputes it

OCPP Backend and Payment Terminal Roles

OCPP connects the charger to a charging management system. It carries authorization, meter values, status, fault reports, and remote commands. It does not process card payments or settle funds. A card terminal or payment service provider handles the financial transaction and returns an authorization result to the backend.

This separation matters during integration. The charger may be online with the OCPP backend but unable to authorize a card because the payment terminal is offline. The screens should tell the driver which payment methods are available, and the backend should record which component failed.

The payment terminal also needs power, network access, tamper protection, software updates, and a secure key. A terminal mounted outdoors must tolerate heat, cold, rain, and physical abuse. Installing a consumer tablet in a charging cabinet is not a payment system.

Plug and Charge and ISO 15118

Plug and Charge uses digital certificates to authenticate a vehicle and contract without a card or app interaction. ISO 15118 defines the communication between vehicle and charger, including the certificate-based authentication process used in many implementations. The charger, backend, vehicle, and certificate authority all have to support the same chain.

The advantage is convenience: the driver plugs in and the session starts. The challenge is operational. Certificate provisioning, revocation, contract updates, and interoperability testing require a mature backend. A site should not advertise Plug and Charge until it has been tested across the vehicles and contracts it expects to serve.

The OCPP 1.6J and 2.0.1 comparison explains how protocol choice affects the backend features available. Payment and Plug and Charge are separate layers, but both depend on reliable communication and data quality.

Roaming, Pricing and Settlement

Roaming lets a driver use a charging network through another provider. The charger sees a roaming identifier, the backend routes authorization to another platform, and the two operators settle the session according to their commercial agreement. The driver sees one price from the provider, while the site operator receives another.

Roaming adds complexity to pricing and support. The site may not know the final retail price the driver paid, and the provider may not control the charger that failed. Tariff mapping, currency, tax, and reconciliation rules should be defined before the site goes live. A settlement report should let the operator trace every session to a payment.

Pricing itself should be transparent. A simple per-kWh price is easier to compare, while time-based or idle fees are sometimes needed to encourage turnover. Whatever the structure, the charger display, app, website, and receipt should agree. Conflicting prices are a fast route to complaints and chargebacks.

Security, Compliance and Support

Payment data is sensitive. Card terminals should use approved point-to-point encryption, tokenization, and tamper detection. The charging backend should not store card numbers if the payment provider can handle them. Access to payment reports should be role-based and logged.

A support process is part of the payment design. Drivers may need a refund, a receipt, or help when a session ends but the app does not update. The operator should have a documented escalation path to the payment provider and the roaming platform. Test refunds before launch, not after the first complaint.

The launch checklist should cover card acceptance, QR flow, app flow, Plug and Charge, offline behavior, receipts, taxes, refunds, and roaming settlement. It should also include a plan for a payment outage. If the card terminal fails, can the charger still start through an approved alternative? If not, staff need to know how to communicate that to drivers.