Toronto’s transit system turned on fare capping on September 1. Pay for 47 trips on the TTC in a calendar month using PRESTO, a debit card, a credit card, or a mobile wallet, and every ride after that is free for the rest of the month. In 2027 the threshold drops to 40 trips. It’s a good policy, and it reads as a one-line press release: pay enough, ride free.
It is not a one-line engineering problem.
New York’s MTA has been running a version of this for a while, a rolling 7-day cap rather than a calendar-month one: 12 paid rides in any seven-day window and the 13th is free, capping a full-fare rider at $35 a week no matter which seven days you pick. Bi-State Development’s Metro Transit in St. Louis went a different route entirely when it rolled out Masabi-powered account-based ticketing in July, baking a flat $5 daily cap and $78 monthly cap into the system from day one rather than layering it onto an existing fare structure. Three transit agencies, three different capping models, and three different back-end problems hiding behind the same rider-facing promise.
That’s the part worth sitting with if you work anywhere near transit payment modernization. Fare capping is a case study in why the back end matters more than the tap.
A closed-loop farecard system, the kind most North American agencies ran for twenty years, stores value or trip entitlements on the card itself, or in a record tied one-to-one to that card number. Capping under that model just means decrementing a counter. Open-loop acceptance, where the rider taps a bank card or phone and never enrolls in anything, breaks that assumption completely. The system doesn’t get a stable card number to build a running total against. It gets a payment token, and it has to recognize on the next tap, milliseconds before the gate has to decide whether to let the rider through, that this token has already produced 12 charges in the last seven days and this trip should be free.
That’s a lookup against a rolling window, evaluated at the edge, fast enough not to hold up a fare gate, and it has to be right, because getting it wrong in either direction is a problem. Undercount and you’re charging riders past their cap, which is a real-money billing error at scale. Overcount and you’re giving away rides the agency needs the revenue from. Do the calculation centrally with any real latency and you’ve either slowed down every tap in the system or you’ve had to let the gate open first and reconcile the charge afterward, which is its own fraud surface.
The calendar-month design TTC picked is the simpler of the three to build, because the reset is fixed and predictable and the reconciliation window is generous. A rolling 7-day window, MTA’s approach, is harder: every single tap has to trigger a fresh count over the preceding seven days, not a lookup against a static counter, and that has to happen for every rider on every vehicle and every gate continuously. St. Louis sidestepped a lot of that complexity by building capping into the ABT platform from the start rather than retrofitting it onto legacy fare media, which is probably the cleanest lesson in the bunch for anyone scoping a new procurement: capping is dramatically cheaper to build in than to bolt on.
There’s a program management thread running under all of this that’s easy to miss if you’re only looking at the technology. TTC had to formally discontinue several monthly and annual pass products as of August 31, specifically because leaving them in the catalog alongside a monthly cap creates a reconciliation and fraud problem: a rider could conceivably benefit from both a pass and the cap simultaneously if the systems aren’t talking to each other correctly. That’s not a payments question. That’s a product-catalog and change-management question, and it had to be resolved before the technical rollout could go live cleanly. Every agency evaluating fare capping is going to hit some version of that same fork: legacy pass products, discount programs, and fare capping all reaching into the same rider account, and someone has to decide which one wins when they overlap.
None of this is a reason to avoid fare capping. It’s one of the more genuinely rider-favorable things a fare system can do, and the three approaches above prove it’s achievable on both legacy-adjacent architecture (MTA, TTC) and greenfield account-based platforms (St. Louis). But it’s a useful reminder that the interesting engineering in transit payments has mostly moved off the card and into the back office, and that’s where the real procurement and design decisions live now.
If you’re in the middle of scoping something similar, or you’ve already hit the pass-versus-cap collision problem, I’d like to hear how you solved it.
High Street Consulting 
Leave a comment