Payment method is usually discussed as a preference and is really an architecture decision. Each option places different requirements on the charger hardware, the backend and the driver, and each fails in a different way.
Most networks end up supporting more than one, because the driver populations they serve are not the same.
What each method assumes
- RFID assumes a card issued in advance and a reader in the charger. Fast, works offline with a cached list, and useless to a first-time visitor.
- App assumes the driver installs software before charging. Rich experience, high abandonment at first use, valuable for repeat drivers.
- QR and mobile payment assumes a smartphone and a payment app the driver already has. Lowest barrier for a visitor, depends on connectivity.
- Plug and charge assumes vehicle-side identity. Best experience, narrowest vehicle support, most infrastructure to establish.
Offline behaviour differs sharply
RFID against a cached authorisation list is the only method that works cleanly with no connectivity, which is why it persists in fleet and workplace deployments despite being the least modern.
Mobile payment methods are the most connectivity-dependent, because the payment itself needs the network. A site with unreliable connectivity and only mobile payment will lose sessions the operator never sees.
Hardware consequences
A reader adds cost to every unit, whether used or not. A display capable of showing a dynamic code adds cost and a failure point. Deciding payment methods after hardware selection means either paying for capability you do not use or discovering you cannot support what you need.
This is a case where a commercial decision should precede a hardware decision, and frequently does not.
Who the driver has a relationship with
An app makes the driver your customer. A card issued by a mobility provider makes them the provider's customer, roaming onto your infrastructure. Mobile payment makes them nobody's customer, a visitor who transacts once.
That difference determines whether you can market to them, whether you know they returned, and who bears the support burden when something fails. It is a strategic choice presented as a payment choice.
Support burden varies
Card problems are usually resolvable remotely. App problems generate support conversations about devices and accounts. Mobile payment problems involve a third party you do not control, and the driver will still contact you.
Sizing support against the payment mix, rather than against session volume alone, produces a more accurate operating cost.
A workable default
Public sites generally need a method that works for a first-time visitor with no prior relationship, plus one that works for repeat drivers. Private, workplace and fleet sites frequently need only cached-credential access, and adding public payment there is cost without benefit.
Deciding by site type rather than by network policy avoids paying for capability that particular sites will never use.