Inside a self-service car wash terminal

Five systems in one enclosure

First, identification: who is standing at the terminal. Second, taking money: notes, coins, card, phone. Third, fiscalisation: the receipt has to reach the tax authority at the moment payment is taken, not later. Fourth, equipment control: the terminal tells the controller which bay to start and for how long. Fifth, telemetry: the owner has to see what is happening without driving to the site.

These five do not merely coexist. They are bound by an order that cannot be broken: money accepted and counted first, then the receipt, and only then the equipment starts. Every attempt to “optimise” that order ends the same way — either the customer paid and got no wash, or got one for free.

Plate recognition: when it is actually worth it

A camera reads the plate on arrival, the system matches it against the customer base and opens their balance. For the customer that means doing nothing: they drive up and the wash starts. For the owner it means regulars come back more often, because it is easier for them.

But it does not pay off everywhere. At a self-service bay, where the driver gets out and picks up a lance anyway, the gain is smaller. At an automatic wash, where they never leave the car, it is decisive. Before paying for recognition it is worth answering honestly which case is yours.

Technically the hard part is not the camera but light and angle. A plate a person reads effortlessly can defeat a camera because of an oncoming headlight or wet snow on the plate. So a working system always keeps a second route in: card, phone, code. A terminal where recognition is the only way in stops working in the first bad weather.

Money: four channels, each failing its own way

The note acceptor is the most temperamental part. Damp notes, creased notes, frost — in winter it is the first to refuse. The coin acceptor is sturdier but needs collection and jams on coins that are not coins. The contactless terminal depends on connectivity: when the line drops it either refuses or runs offline — and then you had better know exactly what happens to those transactions afterwards.

Paying by phone over QR removes most of this, because the mechanics stay inside the customer’s handset. That is why at new sites it often becomes the primary channel and cash the fallback. Removing cash entirely still does not work: some customers pay with nothing else.

The rule that matters for accounting: every channel is counted separately, and at the end of a shift the totals must agree to the last coin. A system that reports revenue as one number with no breakdown makes discrepancies impossible to locate — and sooner or later there will be one.

The fiscal receipt: the quietest place to fail

The receipt has to reach the tax authority at the moment of payment. That is a requirement, but it is also the least visible part of the system: when it stops working the terminal keeps taking money and starting bays, and everything looks fine from outside. The problem surfaces a week later, when the gap has already accumulated.

So fiscalisation cannot be left “for the end, if there is time”. It belongs in the same flow as payment, with its own log: what was taken, what was fiscalised, what was not. The difference between those two numbers is the first thing anyone will look at when it comes to sorting the mess out.

Talking to the controller: Modbus, ccTalk, and why it matters

The terminal washes nothing itself. It only tells the controller which bay to switch on and for how long. That conversation usually runs over Modbus, an industrial standard most controllers understand. For note and coin acceptors it is more often ccTalk or MDB.

The question worth asking before buying equipment: does it expose its data, and over which protocol. A controller with documented Modbus connects quickly. A closed device with no outward channel at all means either replacement or workarounds — and that is the most expensive of the scenarios.

Telemetry: why bother if everything works

While there is one site and it is nearby, telemetry feels unnecessary. By the third site it is the only way to learn about a fault before the customer does. The useful minimum: how much money went through each bay per shift, how long bays stood idle, which errors occurred and when.

More important than a pretty dashboard is that this data exists at all and is kept. A dashboard can be drawn later; data nobody collected will not appear retroactively.

Frequently asked