It's 8:10am on a Red Line platform in Chicago. A community college student pulls a plastic Ventra card from her backpack, taps it against the reader, and puts it away again. The rider next to her taps a phone. Both trains arrive at the same time, but only one of them got there without digging through a bag first.
That gap is not about her phone. You can add a standard Ventra card to Apple Wallet, and Chicago riders have been able to since 2020. Student Ventra cards and RTA Reduced Fare cards cannot be added at all. Ventra's own instructions say so plainly: those cards "cannot be added to the Wallet app at this time." Four years on, "at this time" still means never.
If you run a fare program, a loyalty pass, or any product built on eligibility, you should recognize that line. It describes almost every transit agency's wallet rollout in 2026. Full fare riders got a beautiful contactless experience. The riders who most needed one less thing to carry, students, seniors, people with disabilities, people without a bank account, got left holding plastic. Here is why the two groups split, what closes the gap, and why the cheaper answer was sitting there the whole time.
Tap to pay finally showed up on transit
Contactless fare payment spent most of a decade as a pilot program. It is not one anymore. California went from fewer than 25% of transit trips happening on contactless-capable systems at the start of 2025 to roughly 95% by mid-2026, as the Bay Area's Clipper 2.0 went live in December and Los Angeles rolled out TAP Plus ahead of the World Cup. The Puget Sound region turned on tap to pay across its transit systems in February 2026, letting you ride with a contactless card or a phone in Apple Pay, Google Pay, or Samsung Pay at the reader.
Atlanta's MARTA added its Breeze Card to Apple Wallet this spring as part of a modernization project the agency calls Better Breeze, timed to the same World Cup deadline pushing Los Angeles. New York's MTA has been here longest. OMNY carried 85% of full fare trips and 55% of reduced fare trips by March 2025, up from just 16% of all fares in 2021.
Read the press releases and it sounds finished. Tap a phone, ride a train, done. If you already run a wallet pass program of your own, you know that feeling of a rollout looking finished on the announcement date. What the releases describe is one kind of rider, and you have to look past the headline number to see who they left out.
Two things share a label and nothing else
"Add your transit card to Apple Wallet" describes two different pieces of engineering, and if you have ever scoped a wallet integration yourself, the difference will look familiar.
The version riders keep getting is open loop payment. A contactless bank card, or that card sitting inside Apple Pay, gets treated like cash at the fare gate. The transit agency never has to know who is riding. It settles with the card networks the same way a coffee shop does. This is exactly why it rolled out fast: you do not need a partnership with Apple or Google, just a reader that speaks EMV.
The version almost nobody has is a closed loop transit card, the kind MARTA and Ventra built. This requires a real integration with Apple's or Google's wallet backend, provisioning a virtual card tied to a rider's actual fare account, balance, and pass type. It is slow, expensive, and has to be negotiated agency by agency, the same way you would negotiate a bank-grade partnership rather than ship a feature. New York announced a mobile virtual OMNY card in April 2025, aimed at a late 2025 launch. As of June 2026, there is still no native OMNY card in Apple Wallet. Riders use Express Transit with a personal bank card instead, open loop payment wearing OMNY's fare rules.
Google Wallet runs the same split. Google Pay handles open loop tap to pay in more than 500 cities worldwide, and Google's own closed loop transit ticket program, the equivalent of what MARTA and Ventra built for Apple, is live with a much shorter list of partners: SNCF in France, Hamburg's HVV in Germany, Italo in Italy, and Madrid and Seattle's ORCA more recently. Every one of those required the same agency-by-agency backend work, on a different platform, with the same tradeoff.
Neither version is a wallet pass in the PassKit sense: a signed file with a barcode, an issuer, and fields any reader can validate. That third option barely shows up in this story yet, and it is the one you should be paying attention to.
The riders left out are not an edge case
Follow the fare categories that never made it into a transit card integration and a pattern appears immediately. Ventra excludes RTA Reduced Fare cards, Student Ventra cards, and U-Pass cards from Apple Wallet by name. MARTA's reduced fare program, built for seniors, people with disabilities, and Medicare cardholders, still rides on a physical Breeze Card even as the standard card moved to Wallet this year. New Jersey Transit tightened its own reduced fare verification in January 2026, requiring a photo ID card and retiring the old non-photo version entirely.
None of this is because reduced fare riders matter less to these agencies. It is because a closed loop wallet card ties directly into a payment account, and a discounted or free fare needs an eligibility check a payment rail was never built to carry. Proving someone is a student, a senior, or enrolled in a benefits program is an identity problem. Settling a card transaction is a payments problem. If your own pass program has ever tried to bolt an eligibility rule onto a payment system built for none, you already know which problem is harder.
The riders on the other side of that gap are disproportionately the ones without a smartphone carrying a bank card in the first place. Research on transit payment equity keeps landing on the same finding: tap to pay assumes a credit or debit card, and unbanked and underbanked riders, who skew lower income, do not reliably have one. Build your wallet strategy entirely on payment cards and you recreate the exact barrier you were supposed to remove.
What a barcode pass does that a bank card can't
Baltimore's MTA offers a preview of the other path, and it is worth studying if you are weighing the same build-versus-partner decision. Starting with the 2026 to 2027 school year, students 13 and older in Baltimore City Public Schools get a free 31-day transit pass delivered straight to their phone through the CharmPass app, no bank account or physical card involved. Eligibility comes from a monthly roster the school district shares with the transit agency, tied to a student's school email. The pass auto-renews each cycle as long as that roster confirms the student is still enrolled.
That is an identity check, not a payment rail, solving exactly the problem MARTA and Ventra's card integrations skip. It also did not require a multi-year partnership with a wallet platform to build. Outside Japan and Korea, mobile ticketing built on a scannable barcode rather than an NFC chip has become the default way smaller and mid-size transit operators go digital. Mobile ticketing vendor Masabi counts more than 70 agencies across ten countries on its platform, with new deployments landing in as little as 23 days and some agencies seeing more than half their tickets bought and validated as a barcode on a phone. None of that speed comes from a card network agreement. It comes from a signed file any camera-equipped reader can check, which is the same file format you would reach for if you were issuing a membership card, an event ticket, or an employee badge.
A pass built this way carries the fare product directly: a reduced fare flag, a student expiration date, a monthly cap already reached. A payment card carries none of that. It just moves money and leaves the rules to whatever system reads the transaction afterward, which is exactly the gap you would have to fill yourself if you tried to run eligibility on top of a card network.
Fare capping is about to make the gap worse
Every agency chasing tap to pay is also rolling out fare capping, and capping only works cleanly when the pass itself tracks progress toward the cap. New York's Fair Fares program already shows the strain: about 379,910 residents were enrolled as of March 2026, roughly 31% of the estimated 1.23 million residents who qualify, paying half fare with a $17.50 weekly cap, and 12% of them hit that cap in an average week. Toronto's TTC plans to start capping Fair Pass riders at 47 paid trips a month this September, saving eligible riders around $24.45 off a full month's fares, close to a 20% discount.
An enrollment rate stuck below a third is not only an outreach problem. Every one of those programs still asks a rider to prove eligibility through a channel separate from the fare card itself, an application, a benefits letter, a renewal that lapses quietly. A pass that carries proof of enrollment as a field, not a side process, removes one of the reasons that gap stays open.
A payment card can enforce a cap after the fact, once transactions settle. A pass that shows you your own progress, six of twelve rides used this week, three days left on this pass, turns a fare policy into something you can actually see and trust before you tap. That is a wallet pass problem, not a payments problem, and it only gets harder to bolt on later the longer your wallet strategy stays payments-only.
What to check before you copy the payments-first playbook
If you are scoping a wallet rollout for any kind of eligibility-gated product, transit or otherwise, run the same check these agencies skipped.
Who is your reduced fare rider? Every population your program discounts, waives, or restricts is a population a payment card cannot represent on its own. List them before you pick a technical approach, not after.
What proves eligibility, and who holds that proof? Baltimore's answer was a school roster shared monthly. Yours might be a benefits letter, an ID verification, or an enrollment record you already store. Whatever it is, that proof belongs on the pass, not buried in a backend only your own system can read.
How often does eligibility change? A student graduates. A benefit expires. A senior discount starts on a birthday. A pass that reissues automatically when the underlying record changes stays honest without anyone manually pulling access.
Do you actually need the payment network, or just the wallet? Most eligibility-gated programs never touch money at the point of use. If yours does not, a signed pass with a barcode gets you into Apple Wallet and Google Wallet without a multi-year backend negotiation at all.
The cheaper integration is also the more inclusive one
None of this argues against tap to pay. Riders with a bank card in their phone should keep tapping it, and the agencies rolling that out fast made the right call for that population. The mistake is treating the payments integration as the whole wallet strategy and leaving everyone else on plastic while a slower, harder card integration crawls toward a launch date that keeps slipping, the way OMNY's has for over a year now.
A signed pass with a barcode does not require a seat at Apple's or Google's transit table. It requires an issuer who can verify eligibility once and reissue the pass when that eligibility changes, exactly the CharmPass model, at a fraction of the engineering cost of a closed loop card. You do not have to wait for the next OMNY-style partnership to get every rider off plastic, not just the ones with a debit card in Apple Pay. Passmint issues that kind of pass today, with eligibility, expiration, and live updates built into the file rather than negotiated with a wallet platform first.
Primary sources
Common questions
Technical content writer, Passmint
Julio is a technical content writer at Passmint. He writes about Apple PassKit, the Google Wallet API, and what breaks when wallet passes meet production traffic.
More from Julio Song →