A charging session is not one action

When a driver taps a card at a charging station, it feels like a single, simple action.

A short beep.
A confirmation on the screen.
The session starts.

From the outside, nothing suggests complexity.
But that small gesture triggers a chain of systems and decisions that most people never see. And many professionals never fully map out.

Here’s what is typically happening in the background, almost instantly, when that card touches the reader.

What the charger actually sees

First, the identifier on the card is read and translated into a digital request.
The charger doesn’t know who the driver is in a human sense. It only sees an ID that must be interpreted correctly. That ID already carries assumptions about format, ownership, and scope.

Second, the charger forwards this request to a backend system.
This handover matters. The charger is not deciding whether charging is allowed. It is asking a system upstream to decide on its behalf.

Where decisions are really made

Third, authentication logic kicks in.
The backend checks whether this identifier is valid, active, and permitted to start a session at this specific location.

Fourth, external systems may enter the picture.
If the identifier belongs to a different provider, requests and responses cross company boundaries. Contractual rules, and technical compatibility suddenly matter, even though nothing about the tap itself changed.

Fifth, pricing rules are referenced.
Applicable tariffs and pricing logic exist, but how and when prices are surfaced depends on the charging and payment model involved.

Sixth, authorization rules apply.
The system determines whether a session may start under the current conditions. A positive response allows charging to begin, but does not imply that all outcomes are already fixed.

How a session becomes “real”

Seventh, a session context is created.
IDs are generated. Timestamps are set. Relationships between charger, user, backend, and commercial logic are established. This context will later determine how the session is reported, settled, and analyzed.

Eighth, communication protocols take over.
Messages are exchanged in a defined order, with expectations around timing and acknowledgment. If these expectations are misaligned, failures can emerge in subtle ways.

Ninth, operational visibility begins.
The session becomes visible to monitoring, support, and operational systems. Whether anyone is actively watching is another question, but accountability now exists.

Why failures rarely have a single cause

Tenth, responsibility is distributed.
From this moment on, multiple systems and often multiple companies are jointly responsible for the outcome of a single charging session. No single party owns it end to end.

All of this happens in seconds.

In practice, discussions about failed charging sessions often start with a simple question:

Was it a hardware issue?
Or was it a software issue?

That question is understandable, but it is usually too narrow.

As described above, a charging session is not carried by a single component.
It depends on many links in a chain: devices, backend systems, external partners, rules, and processes that must stay aligned at the right moment.

When something goes wrong, the cause rarely sits cleanly on one side.
Not purely hardware.
Not purely software.

More often, it emerges somewhere between those elements.
At a handover, an assumption about how the other system behaves,
or an interaction where each part works as intended, but not in the same way.

And it explains why resolving charging issues so often requires coordination across teams and systems. Not just fixing a single component.

We’ll continue from here.

Before reading this, was this background flow clear to you in this form?