On the night of May 18, 2026, Clipper 2.0 went dark across the Bay Area. Ticket vending machines threw a cryptic “verify failure and limit” message, fare inspection devices dropped offline, and riders couldn’t check their account balances. The outage ran close to 24 hours. When the Metropolitan Transportation Commission finally got an answer out of Cubic Transportation Systems, it wasn’t a server failure or a bad code push. The vendor had missed a telecom bill, and AT&T had cut the circuit.
I keep coming back to that detail because it captures something people miss when they talk about account-based ticketing: the hard part was never the tap. It’s everything behind it.
Clipper 2.0 is Cubic’s rebuild of the back end that clears fares for 22 Bay Area agencies, including BART, Muni, and AC Transit, under a $461 million contract with MTC. It launched December 10, 2025, replacing a closed-loop system where the card itself held the balance. The new architecture flips that: the card or phone is just an identifier, and the actual ledger, the fare caps, the transfer logic, lives in Cubic’s servers. That’s the whole point of account-based ticketing. It’s what lets an agency cap fares automatically, merge family accounts, or let a rider tap a bank card they’ve never registered anywhere. But it also means every rider’s history, balance, and payment method has to migrate off the old system and into the new one without losing a dollar.
That migration is where this has gone sideways. MTC and Cubic have logged ten major incidents totaling more than 33 hours of downtime since launch, and bulk account migration, moving the bulk of existing Clipper balances into the new platform, slipped so far that Cubic only expected to start testing it by the end of May. MTC is now funding the original Clipper system to keep running in parallel into 2027, at a cost of $3.4 million, specifically so riders have a fallback while the new back end stabilizes. Customer service staffing is up by $7.6 million because the call center is fielding roughly 35,000 calls a month against capacity built for steady-state volume, not a live migration. BART alone lost $386,005 in fare revenue during one outage, reimbursed by MTC. The agency’s board has scheduled closed sessions to weigh contractual remedies and has not ruled out litigation.
None of that shows up in a demo of the tap reader. It shows up in the unglamorous parts of a transit payment modernization program: data migration runbooks, parallel-run budgets, vendor SLAs that specify uptime and operational obligations like, apparently, paying your own subcontractors. Account-based ticketing concentrates risk in a way closed-loop cards never did. A dead card reader used to mean one broken gate. A dependency failure in a centralized back end means every agency on the platform is exposed at once, which is exactly what happened in May.
Here’s the part that makes this worth watching past the Bay Area: Cubic is also the vendor SEPTA picked for SEPTA Key 2.0, a $211 million contract awarded back in January 2025, with design and implementation now underway and a targeted completion in 2029. Philadelphia isn’t starting from scratch on account-based ticketing, which cuts both ways. There’s a real benefit in Cubic reusing architecture it’s already built once. But the Clipper experience is a live case study in exactly which assumptions to pressure-test before go-live: how migration volume is tested against realistic account counts and not a clean sample set, what financial remedies exist if uptime or subcontractor obligations aren’t met, and whether there’s budget set aside up front for a parallel legacy run rather than scrambling for emergency funding after the fact. Any agency running a contactless fare collection project right now, not just SEPTA, should be treating MTC’s board minutes as required reading.
The broader lesson for anyone building a transit payment modernization roadmap is that the credibility of account-based ticketing rests on back-end discipline, not front-end polish. Readers and apps are the easy 20%. Migration tooling, vendor accountability, and contingency funding are the hard 80%, and they’re exactly where programs get judged after launch day, when nobody’s watching the ribbon-cutting anymore.
If you’re in the middle of a fare system migration, or about to sign a contract for one, I’d genuinely like to compare notes on how you’re structuring the vendor accountability piece. It’s the part of these programs that gets the least attention during procurement and the most attention six months after launch.
Leave a Reply