Specify the fare system for the coldest morning of the year

Every fare system I have seen procured in Canada was chosen after a demonstration held indoors. A validator sits on a table in a meeting room, a vendor's engineer taps a card, a green light appears and the evaluation panel moves on to the back-office reports. I have given that demonstration myself. It proves that the product works on a good day, which is the one condition an agency already knows it can manage.

The question that decides whether a fare system serves riders is a different one. What happens at twenty to seven on a January morning when the bus has been parked outside overnight at minus thirty-four, the driver has just started the engine, the doors open at the first stop, and a rider who has never used the system taps a bank card on a reader that is still warming up, out of mobile coverage, with eleven people queuing behind? A fare system has to answer that question in about half a second. Most specifications never ask it.

The demonstration is always warm

In December 2021 we put our new validators on forty buses at a prairie agency. They had passed laboratory tests at minus thirty. In the first deep cold of that winter, 11 per cent of them took up to twenty minutes to read cards after a cold start, and some rebooted as condensation formed inside them once the bus heated up. Nothing in the laboratory had reproduced a door opening thirty times an hour on a bus whose interior swung between minus twenty and plus eighteen. Drivers saw the problem within a week. We heard about it later.

We held the launch for eleven months and retrofitted 2,300 validators. The lesson I took was not really about heaters. It was that the specification we had written, and the one the agency had approved, described a product in steady conditions. It said how fast a tap would be processed, how many taps a day the back office could handle and how quickly a report would run. It said almost nothing about what the validator would do when it could not do those things.

Most of the failures riders experience are of that kind. Mobile coverage vanishes in underpasses, on the rural stretches of regional routes and, in some cities, in the same few blocks every day. Back offices go down for maintenance. Card-scheme rules change. Screens freeze, touchscreens ignore gloved fingers and phone batteries die in the cold before a rider reaches the stop. None of this is exotic in Canada. It is February.

Failing open is a fare policy, not a firmware setting

When a validator cannot complete its usual checks, it has two choices. It can refuse the tap, in which case the rider is either turned away or waved through by a driver who must now judge fares as well as drive. Or it can accept the tap, store it securely and settle it later, accepting a small risk that the card turns out to be unpaid. In our industry this is often treated as a technical setting, chosen by the vendor's engineers and left in a configuration file nobody reads.

I think that is a mistake. Whether a validator fails open or closed decides who carries the cost of the system's failures: the agency, through a little lost revenue, or the rider, through a refused boarding at minus thirty. It also decides what drivers are asked to do, which in a unionised workforce is a matter for collective agreements, not firmware. It is fare policy, and fare policy belongs to the agency's board.

At Halvery we now ask every agency to decide this in writing before launch, and we show it the evidence. Since 2023 offline acceptance has accounted for about 0.2 per cent of taps across our customers, and revenue lost through cards that later failed payment has stayed below 0.1 per cent of fares. Each agency sees those figures for its own system every month. Several revenue managers who argued for failing closed in 2022 have looked at their own numbers and changed their minds. One has not, for reasons I respect: her routes rarely lose coverage, so the exposure is not worth carrying. The point is not that every agency should choose as we would. It is that someone accountable should choose.

The same principle reaches beyond the validator. Our trip planner now says plainly when an arrival estimate comes from the timetable rather than a live vehicle position, instead of showing a confident time it cannot support. Our specialised-transit booking continues to take telephone bookings when the app is down. Each of those is a decision about who bears a failure, and each is written into the specification rather than left to chance.

Three questions for an evaluation panel

Agencies can change this without becoming engineers. I would suggest three questions to any panel evaluating a fare or rider-information system, including one evaluating ours.

First, ask for the degraded-mode specification as a separate document. For each component it should say what happens with no network, with no back office, with a frozen display and below minus thirty, and who chose that behaviour. If a vendor cannot produce it, the product has not been designed for those conditions, whatever the demonstration showed.

Second, require a field test in the conditions the agency will actually face before any payment that depends on launch. In a prairie city that means January. On the coast it may mean salt spray and months of rain. A field test costs a vendor time and money, and an honest vendor will price it into the bid. A vendor who resists it is telling the panel something useful.

Third, ask for monthly reporting on degraded operation after launch: offline taps, cold-start failures, arrival estimates shown without live data and the revenue at stake. These numbers are usually small, which is exactly why they are seldom reported. Visible, they can be managed. Hidden, they become a driver's problem and a rider's experience.

There is a cost to all of this, and agencies should hear it from vendors directly. Products built for degraded conditions take longer to design and more to test. Our validators now cost about 9 per cent more than the version that failed. Our release plan includes a winter that cannot be shortened. Some agencies, offered a lower price for a product specified only for good days, will take it, and I understand why: operating budgets are tight, and the bad morning is hypothetical until it arrives.

Riders do not live on the average day, though. They live on the morning when the bus is late, the screen is frozen and the wind is coming off the river. A fare system should be judged on that morning, because that is when a rider decides whether public transit deserves their trust.