Unattended payments: what actually breaks outdoors

Vendor brochures describe unattended payments as a solved problem: install the terminal, take the money. The parts nobody puts in a brochure are the ones that decide whether the site earns or loses. This is written from a car wash network that has run for years, in a country where minus fifteen in January is ordinary.

The note acceptor is the first to quit

In an office demo it takes every note. Outdoors it meets damp notes, creased notes, notes that spent a week in a coat pocket. Below zero the mechanism slows and the rejection rate climbs. The customer does not think “the acceptor is cold” — they think the machine is broken and they drive to a competitor.

Two things follow. First, every site needs at least one payment route with no moving parts: contactless, or QR from a phone. Second, the rejection rate belongs in your telemetry. A steadily rising rejection count is a fault developing, and it is visible days before anyone phones to complain.

Offline is a normal state, not an emergency

Mobile coverage at an industrial site is not a promise. The link drops weekly, sometimes for hours. Any design that assumes connectivity produces a terminal that stands idle with a spinner while the customer waits with a car full of foam.

A terminal that works has to take cash, start the bay and record the transaction with no network at all, then reconcile when the link returns. That is not a nice-to-have, it is the baseline. The questions to settle at design time: which payment routes survive offline, how long the backlog can grow, and who sees that it is growing.

Payment and delivery are separated in time

This is the part that trips up software written for retail. In a shop, money and goods change hands at the same moment. At a wash the customer pays and then uses six minutes of service. If the terminal loses power in minute two, what is owed?

There has to be an explicit answer, agreed before anything is built: does the remaining time survive a restart, is it credited back, is there a balance the customer can spend later. Systems that never decided this end up refunding by hand, from a manager’s judgement — and that is both expensive and unfair, because the judgement differs by manager.

Reconciliation is the part that gets skipped

Four payment routes — notes, coins, card, QR — mean four counters, and they must be counted separately. A single tidy revenue figure looks fine right up to the day it does not match the cash in the safe, and then there is no way to locate where it went wrong.

The same applies to receipts: what was taken and what was fiscalised are two different numbers, and their difference is the health indicator of the whole installation. While it is zero, the site is fine. When it is not, something broke — and it is better to learn that from your own dashboard than from an inspection.

Talking to hardware that does not want to talk

Controllers speak Modbus. Note and coin acceptors speak ccTalk or MDB. Card terminals speak whatever their acquirer defined. None of them was designed with the others in mind, and the job is largely teaching them one common language.

The question worth asking before buying anything: does this device expose its data, and is the protocol documented. Equipment with documented Modbus integrates quickly. A closed device with no outward channel means replacement or a workaround, and that single answer moves a project’s cost more than anything else in the specification.

What separates a site that earns from one that annoys

The common failure at launch is doing the first two jobs — taking money and starting the equipment — and skipping the last two: accounting and telemetry. The bays work, the money comes in, and the owner still does not know what the site earned yesterday and hears about faults from customers.

Those last two are not reporting features. They are what turns a machine into a business: without them there is no way to tell a slow week from a broken acceptor, and no way to know which of three sites is quietly losing money.

Frequently asked

Can unattended payments run without cash at all

Technically yes, and it removes the most failure-prone hardware. In practice it depends on the market: in some places a meaningful share of customers still pays with nothing but cash, and removing it removes them. The honest approach is to measure the cash share on your own sites before deciding, rather than following a general trend.

How do we handle a customer who paid and got nothing

By deciding the rule in advance and implementing it, rather than handling each case by hand. The usual options are crediting the remaining time to a balance the customer can use later, or an automatic refund through the original payment route. Both are acceptable; manual case-by-case judgement is not, because it differs by manager and cannot be audited.

Does this work with equipment we already own

Usually, if the controllers expose their data over a documented protocol. That single question — documented interface or not — determines most of the cost. It is worth answering before buying equipment, not after.