Car wash payments: from the bay controller to reconciliation

At a self-service car wash money arrives by four different routes, and each one fails in its own way. Here is how it works from the bay controller to the end-of-shift reconciliation, and why a shortfall is almost never found in the till — it is found by matching two logs against each other.

Four routes the money takes

Coins and tokens. The oldest route: the coin mechanism counts, the controller adds time. Simple, but it requires collection runs, and this is where a discrepancy is easiest to miss.

Notes. A bill validator with a cassette. More money per visit and fewer collections, but it adds a cassette, counterfeits and a separate event log.

Card at the bay. A contactless terminal on the pedestal. Convenient for the customer, but a terminal per bay is the most expensive option across a network.

QR and app. The customer pays from a phone and the bay gets a command from the server. Cheaper than terminals, gives you an account per customer and room for discounts — but it needs connectivity and a working server, which moves the risk from hardware into infrastructure.

Who believes whom

The central architectural question is what counts as the fact of payment. If the fact is the bank’s message, the bay will start even when the money never settles. If the fact is the controller’s reply, the customer can pay and get no time because the link dropped.

The working answer is two independent events and a reconciliation between them: "payment accepted" and "time dispensed". Both are written with a timestamp and a bay number, and by end of day every payment must have a partner. A payment without a dispense is a customer complaint that has not arrived yet. A dispense without a payment is either a fault or abuse.

That pairing, not the cash in the till, is the real accounting. The till shows what is left; the pair shows what happened.

What breaks most often

Connectivity. At a roadside wash mobile data drops regularly. A system that refuses to start a bay without internet loses revenue exactly at peak hours. The correct behaviour is local operation with events buffered and sent when the link returns.

Power. A sag at the moment the pump starts upsets the terminal or the validator. The classic signature: failures happen only on the most powerful programme and almost never at night.

Time. A controller with its own clock and no synchronisation drifts away from the server. A month later shift reconciliation stops adding up, and the cause is looked for in people rather than in the clock. Store time in UTC, display it local, synchronise regularly.

Three numbers the owner should see daily

Revenue per bay per day. Not the site total — per bay. A bay suddenly earning half of its neighbour almost always has a technical reason, and that reason is visible in a day rather than in a quarter.

The count of payments with no matching dispense. Zero is normal. Any other number needs an explanation the same day.

Downtime per bay. A bay that did not work for four hours on a Saturday costs more than any feature in the system.

Everything else — charts, conversion, average ticket — is nice but not daily. Three numbers every morning beat twenty charts once a month.

Where the revenue leaks

Most often not through theft but through silence. A bay is down and nobody noticed; the validator jammed overnight and was opened at noon; the terminal dropped off and customers simply drove away. A fault alert pays for itself faster than any analytics.

Second place: manual starts. The ability to run a bay without payment is needed for maintenance, and it is also the simplest way to take money. The fix is not a ban but a log: who, when, how many minutes, for what reason. A log nobody reads still works — people behave differently knowing the event is recorded.

Third: price mismatch. The price in the controller, on the sign and in the app must come from one source. When there are three, sooner or later they diverge, and you will hear about it from a customer.

Frequently asked

Is a terminal per bay better than one terminal for the site

One terminal per site is cheaper but creates a queue and ties the payment to a specific bay through an extra step. In practice QR often wins across a network: the customer pays from their own phone and no per-bay terminal is needed at all. The decision depends on the share of customers willing to pay by phone — and that share is worth measuring rather than guessing.

What if the bay controller is closed and exposes nothing

The options are the same as in any equipment automation: replace the controller, take signals physically (pulses, a current sensor on the pump), or obtain the interface from the manufacturer. Physical signals give less data, but the fact of operation and its duration are usually enough to close the reconciliation.

How long does it take to add payments to an existing wash

The honest answer is that it depends on what is already installed, and it cannot be given without a site visit. What genuinely shortens it: controllers with a documented interface. What stretches it: closed equipment and no access to the current acquiring contract. Specific timelines are given after a survey, not over email.