The Ferry Ticket That Outlived the Machine

In late October 2012, a ferry became one of the few ways in and out of Manhattan. Hurricane Sandy had flooded subway tunnels and closed roads. At the ferry terminals, the ticket vending machines were out. But NY Waterway’s phone app, built with Bytemark, could still sell a ticket. It was an unusually clear demonstration of software’s value: a system matters most when the familiar one goes dark.

Bytemark co-founder Nick Ihm later described the app as the only way to pay the fare in that moment. This is his recollection, rather than a claim that every ferry rider owned a working phone. The larger point survives the distinction. A transit payment method cannot be judged only by how it looks on an ordinary Tuesday. It must also survive the Tuesday when the machine is broken, the queue is growing and someone needs to get home.

The phone was the opening act

Founded in New York in 2011, Bytemark first talked about mobile ticketing and a mobile wallet for merchants. The NY Waterway app arrived in January 2012. Riders could buy a fare before boarding and show a visual ticket rather than find a machine or handle paper. For an agency, the attraction was broader: software could distribute tickets without another vending box at every stop.

The ferry proved an entry point, then the work multiplied. A ticket has to be sold, paid for, displayed, checked, refunded when appropriate and recorded in an agency’s accounts. A bus operator may accept a glance at a screen; a rail gate may need a barcode or card token; an inspector needs a different view again. Bytemark’s answer became a set of connected services, not a prettier ticket icon.

“Our mobile app was an easy way - in fact, the only way - to pay the fare to get in and out of Manhattan.”Nick Ihm, Bytemark co-founder, recalling Hurricane Sandy

By 2016, Bytemark said it served more than 20 transit operators and processed $30 million in ticket value a year. NY Waterway was selling half its tickets through its white-label app, according to the company’s funding announcement that year. Those are historical company figures, and they show why the pitch had changed. It was no longer an experiment in whether a passenger would use a phone. It was about how many parts of a fare system the phone could connect.

Four jobs behind one fare

Today the company packages much of that machinery as Bytemark Bridge. Passage handles ticket buying, inspection and validation. Connect ties a barcode or smartcard to an account, so the fare is calculated against the rider’s record. Transact covers gateway services, wallets and fraud tools. Navigate brings trip information and communications into the same journey. Each can be deployed separately, and the company advertises open APIs for integrating installed equipment.

This breadth matters because agencies rarely begin with a blank sheet. They have gates, card readers, vending machines, inspectors, fare rules and agreements with neighboring operators. Replacing all of it at once is expensive and politically awkward. Bytemark’s advertised distinction is a configurable backend and hardware-agnostic validation layer. The practical promise is to add a digital way to pay while the existing system continues to serve riders.

The price of convenience

A transit agency pays for much more than an app download. In 2016, Des Moines Area Regional Transit approved a Bytemark mobile-ticketing contract capped at $590,000 across four years. The figure covered software, installation, hosting, transaction fees, warranty, options and maintenance. It is a specific procurement, not a universal price list. It usefully punctures the notion that digital ticketing is free simply because no new paper is printed.

The model is business-to-business: agencies contract for software and services, while riders use agency-branded apps or Bytemark’s shared Journey app. The back office handles reporting, support and integrations. Payments generate transaction work. That can be attractive to an operator trying to avoid a large one-off hardware replacement, though the economics depend on the agency’s existing system, volume and contract terms.

Bytemark raised $9.5 million in 2016 from Siemens Venture Capital, INIT and existing investor HaCon, among others. HaCon acquired a majority stake in 2017 and Bytemark now presents itself as a Siemens company. That ownership changed the scale of its market access: a fare app could sit beside a broader portfolio of planning, ticketing and fleet tools. It also means any account of Bytemark today should describe its Siemens relationship, not leave it frozen as a standalone startup.

The rider who pays cash

The first thing a mobile fare system can fail is access. A passenger may have a phone but no payment card; another may need a discounted fare but cannot afford a monthly pass upfront. Bytemark’s work with Austin’s Capital Metro addressed both. In 2020, riders could load cash into an app wallet at more than 250 local retail locations through InComm Payments. The agency also piloted fare capping: after enough single rides, the rider received the benefit of a pass without buying it at the start of the month.

The pilot was limited to up to 200 participants for six months and aimed at eligible riders in health and human-services programs. That limit matters. The lesson is a product design choice, not proof that every rider got a better fare. In Sacramento, Bytemark connected its ZipPass app to fare vending machines so cash users could buy mobile tickets there. These are unglamorous integrations, but transit cannot be equitable if its newest payment method requires a banking relationship many riders do not have.

Bytemark’s partnerships reveal the same practical bent. Moneris helped add Apple Pay, Google Pay and Interac Debit to York Region Transit’s app. Advanced Mobile Payment supplied contactless-capable terminals for Toronto’s Union Pearson Express. INIT worked with Bytemark on San Diego’s regional fare system. Each partnership solves a local constraint that a standalone app cannot wish away.

The copyable part

An agency considering mobile fares can copy Bytemark’s sequence. Start with a real boarding pain point. Map how tickets are bought, validated and reported before choosing an app screen. Keep cash and reduced-fare riders in the design. Then test the new method beside the old equipment rather than assuming a launch ends the job. The sequence works best where operators can integrate their data and payment rules; it becomes harder when fare policy is fragmented, phones are scarce or procurement cannot accommodate ongoing service fees.

Bytemark’s shared Journey app, launched in 2022, extends that logic to smaller deployments. In 2023, Hampton Roads Transit used it for Virginia Beach shuttle tickets aimed at summer visitors. Instead of commissioning a separate app for a seasonal route, the agency joined a platform that already carried multiple operators. A modest use case is often more revealing than a grand citywide promise: a visitor needs a ticket, a driver needs to recognize it, and both need the transaction to work the first time.

The ferry story still makes the strongest test. The celebrated object was a phone ticket. The actual achievement was keeping a route usable when the normal means of paying had failed. Bytemark’s later products are more complicated, but they answer that same question at a larger scale: what has to keep working so someone can board?