Requiring a driver to install an application before they can charge is the largest single point of abandonment at a public charger. QR payment removes it, which is why it has become the default expectation in markets where mobile payment is ubiquitous.
It also introduces failure modes that an app-based flow does not have, and most of them are about what happens between authorising the payment and delivering the energy.
Static and dynamic codes are different products
A static code printed on the charger identifies the charger and nothing else. Amount, session and connector are established afterwards, which means the code cannot carry a transaction and cannot expire.
A dynamic code is generated per session and encodes the specific transaction. That makes reconciliation far easier and requires a display capable of showing it, plus connectivity at the moment of generation.
Printed codes are a security exposure
A sticker can be covered by another sticker. This has happened widely enough in other payment contexts to be a known attack, and a charger in an unattended car park is an easy target.
Mitigations include tamper-evident materials, codes displayed on screen rather than printed, and drivers being shown the merchant identity before confirming. None is complete on its own.
The pre-authorisation problem
At the moment of payment the final amount is unknown, because the session has not happened. Systems either take a fixed amount and reconcile later, hold an authorisation and capture the actual value, or bill after the fact against an identity established at the start.
Each has consequences for the driver: a held amount that appears on their statement, a refund cycle they did not expect, or a later charge they may dispute. Choosing between them is a customer experience decision as much as a technical one.
Where sessions and payments diverge
Each needs a defined behaviour. Systems without one accumulate manual reconciliation work that grows with volume.
- Payment succeeds and the session fails to start, requiring a refund path that works without human intervention.
- The session starts and the payment is later reversed, leaving energy delivered and unpaid.
- The session delivers less than the pre-authorised amount, requiring partial capture or refund.
- The charger loses connectivity mid-session, leaving the final amount unknown at settlement time.
Connectivity is now on the payment path
A charger that cannot reach the backend cannot generate a dynamic code or confirm a payment. QR payment therefore makes connectivity a revenue dependency rather than only an operational one.
Sites with marginal connectivity should consider that before choosing QR as the primary method, or provide a fallback that does not depend on it.
Reconciliation is the real work
Every session must map to a payment and every payment to a session, with the exceptions identified rather than absorbed. Without that mapping, revenue leakage is invisible: you cannot detect what you never expected to receive.
This is unglamorous and it is where the money actually is.