TapFlow
Apple Wallet Transit has the right starting grid. TapFlow is the race strategy, telemetry, and finish-line system that gets every rider to the chequered flag.
This project is a structured product strategy exercise built for the Manager, Transit Product Management role on the Apple Wallet, Payments and Commerce team.
The problem framing, system architecture, partner integration model, launch strategy, and measurement framework draw from Apple's public documentation, official transit agency publications (MBTA, SEPTA, OMNY, ORCA), peer-reviewed transit research, and publicly available adoption data. Sources are cited throughout as through.
Several sections (concept scoring, preference testing structure, and the technical build phases) are written as “how I would approach this” rather than as executed deliverables. These are labeled throughout. Where the work is directional, it reflects genuine product process thinking applied to a documented problem, not a hypothetical exercise.
The goal is to show how I think, how I structure genuine complexity, and how I would operate in this role from the first week.
Apple Wallet Transit has a clear promise.
The tap is not the finish line.
Tap. Ride. No physical card needed. No unlock. No app. No friction. Apple already delivers this for most riders in most supported cities. iPhone, Apple Watch, Express Mode, open-loop payment cards, agency transit cards, and city-specific integrations are live.
But the rider's actual journey from intent to completed ride has many more steps than “tap.”
- Wrong credential activates at the gate
- Reduced fare not applied; full fare charged silently
- Apple Watch creates a separate fare cap from iPhone
- Commuter Rail excluded; rider finds out at the gate
- Partner app required to add transit card to Wallet
- Card clash: reader charges an unexpected credential
- Tap-in on iPhone, tap-out on Watch; fare unresolved
- Tap fails; no explanation, no recovery path shown
- Which city, which network, which service, which fare product
- Which credential is active in Express Mode on which device
- Whether iPhone and Apple Watch token are the same fare identity
- Whether reduced fare is enrolled and linked to the payment card
- Whether the validator accepts open-loop on this specific service
- Whether a partner app is required to provision the transit card
- Which entity (Apple, issuer, agency) caused a failed tap
- What the correct next action is after a failure
“The rider experiences Wallet Transit as one promise: tap and ride. But the outcome depends on a hidden system of variables: city, network, service, credential, device, fare product, agency rules, and reader behavior.”
Four Business Outcomes
Contactless transit has moved past proof of concept. A small percentage of failed, confused, or incomplete experiences now affects large absolute numbers of rider moments.
MBTA contactless taps by July 2025, up from 904,000 in the first full month live (August 2024). At 1% failure, that is 31,700 broken rider moments per month.
SEPTA contactless payment revenue generated before Regional Rail expansion. Every friction point in setup or recovery has a downstream revenue cost.
U.S. cities where Apple Pay for transit is now live as of June 2026, with Dallas and Houston added recently. Each market launch carries the full spectrum of credential, device, and fare complexity.
Transit agencies globally covered when Transit App built a dedicated “where can I tap?” feature in 2025. Third-party tools do not build this infrastructure unless rider uncertainty exists at scale.
OMNY taps recorded by NYC MTA by October 2025, with 68% made via digital wallets in phones and wearables. Two million riders now use OMNY daily. At this scale, even a small failure rate is a significant operational event.
Apple Services revenue in fiscal Q2 2026, an all-time record. Transit is among the highest-frequency Apple Pay touchpoints, a daily habit loop that compounds Services engagement, Apple Watch attach, and device retention.
Every setup failure is a rider who intended to use Wallet Transit but did not successfully activate it.
Correctly provisioned riders create future trip volume. Failed setups reduce engagement across the ecosystem.
Agencies need to know that Apple's experience reflects their fare rules and their service boundaries accurately after launch.
Apple promises simplicity, privacy, and security. Friction or failure at the first gate undermines that promise at the moment it matters most.
Why Apple Has Both the Motive and the Obligation
A daily commuter taps 40+ times per month. No other Apple Pay touchpoint (retail, boarding passes, hotel keys) comes close to that cadence. Each successful tap deepens the Services habit loop that drives Apple's highest-margin revenue line.
Express Mode operates for up to 5 hours on power reserve on iPhone XS and later. For a daily transit rider, “my phone is my transit card even when it's dead” is a switching cost Android fragmentation cannot easily replicate. A silent retention mechanism built into every commute.
The parity window is open. Apple has a structural lead in NFC transit across 14 US cities. Closing the access completion gap now, before Google ships a comparable experience, turns the lead into a compounding standard rather than a temporary advantage.
The car is excellent.
The race can still end early.
In Formula 1, a DNF is not always the driver's fault. It can be reliability, strategy, coordination, or a single subsystem failing at the wrong moment. Apple Wallet Transit has the same risk profile. The starting grid is strong. The race can still end before the chequered flag.
Service Blueprint · From Grid to Chequered Flag
| Stage | Starting Grid | Lap 1: Setup | Lap 2: Tap | Lap 3: Fare Outcome | Lap 4: Recovery |
| Rider | Opens Wallet or approaches station | Adds card, configures device | Taps iPhone or Watch | Boards, transfers, exits | Reviews charge, seeks help |
| Frontstage (Wallet) | Credential selection | Express Mode, device choice | NFC credential presentation | Fare status (if available) | Recovery screen (if shown) |
| Backstage (System) | Provisioning, token, partner rules | TransitIdentity state, fare context | Validator, TSP, payment network | Agency fare settlement, cap tracking | Reason code, support routing |
| DNF Risk | No transit identity concept; rider starts without context | Wrong credential, no Express Mode, partner app required | Card clash, unsupported service, wrong device | Fare cap resets, reduced fare not applied, device switch | No recovery shown, unclear ownership, rider abandons |
The 5 Whys
| Why | Finding |
|---|---|
| Why do riders use the wrong credential, miss fare caps, or face gate failures? | Wallet presents transit options without knowing which credential is correct for the specific city, service, and fare type. |
| Why doesn't Wallet know? | There is no structured transit identity layer that connects rider, device, credential, agency rules, and fare context in one place. |
| Why is that layer absent? | Transit fare rules and service eligibility are local, conditional, and historically expressed as static documentation rather than machine-readable metadata. |
| Why is metadata not structured? | Apple, agencies, payment networks, and TSPs each hold different parts of the information. No shared model integrates them at provisioning time. |
| Why are they fragmented? | Wallet Transit launched as a payment method extension. The access fulfillment layer, connecting credential to fare eligibility, device to fare identity, was left to rider knowledge and agency documentation. |
Root cause: Transit access is a fulfillment problem wearing a payment problem's clothes. The payment credential works. What is missing is the orchestration layer that connects rider intent, credential state, device behavior, agency fare rules, service eligibility, and recovery paths into a complete access outcome.
Good rider configures the wrong credential or Express Mode state and does not know until the gate declines them.
Good rider switches device or card mid-journey and loses fare cap progress or transfer window silently.
Good rider attempts a service Apple Pay does not support, and reaches the gate before finding out.
Rider cannot tell whether Apple, the card issuer, or the transit agency caused the failure. Trust erodes for all three.
Multi-Sided Ecosystem
The Person Riding
Wants to tap and board. Should not be required to understand fare system architecture, validator behavior, or token identity to ride a bus correctly.
Apple
Owns Wallet, device security, privacy model, and the ecosystem. Uniquely positioned to connect device signals, payment credentials, and partner rules into a coherent access experience.
Transit Agencies
Own fare policies, service boundaries, validator behavior, and reduced fare eligibility. Need Apple to reflect their rules accurately, without requiring them to redesign their fare infrastructure.
Payment Networks / TSPs
Operate token lifecycle management and see patterns across the full ecosystem. A single agency cannot see what a network can see about token behavior and fraud.
Fraud and Support Teams
Need fewer support contacts after launch, a clearer failure taxonomy, and faster incident resolution when a new market goes live or a fare rule changes.
Legal and Privacy
Ensure fare account linking, identity verification, and trip data usage remain consented, minimal, explainable, and compliant across regions and regulatory frameworks.
What riders actually want
Riders do not think about credentials, tokens, or fare cap rules. They have a job: get on the train. TapFlow is built around five jobs that transit makes harder than it should be.
"When I approach a transit gate, help me tap through without having to think about which card or device to use."
Correct credential on the correct device. First time. No decision required.
"When I plan a trip that uses a service I have not tried before, help me know whether Apple Pay will work before I am at the gate."
Preemptive service eligibility clarity: shown before the station, not after the decline.
"When I am entitled to a reduced fare, help me pay the right amount without managing a separate card or enrollment separately from Wallet."
Fare accuracy at the tap point. Not discovered as an overcharge on a bank statement three days later.
"When I switch between iPhone and Apple Watch, help me not lose my fare cap or transfer window."
Continuity of fare identity across device changes, or a clear warning before continuity breaks.
"When a tap fails, help me understand why and get on the train without embarrassment, delay, or confusion about who to call."
Actionable recovery within seconds of failure. Specific next step, not a generic error state.
How I would research this problem
At high-traffic fare gates in Boston, New York, and Seattle. Goal: observe credential selection, failed taps, and recovery behavior in context, not in recall during an interview.
Categorize Apple Wallet and agency support contacts by failure type: wrong fare charged, Express Mode misconfigured, commuter rail excluded, tap-in/tap-out confusion, device switch confusion.
Talk with agency launch ops, customer support, and fare technology teams to understand: which failures create the most support volume, what data they can and cannot share, and what they most need Apple to handle upstream.
Analyze iOS Wallet reviews and transit agency app reviews for patterns: “wrong amount charged,” “card not working,” “did not know commuter rail was excluded,” “could not add card without the app.”
Talk with transit payment specialists, EMVco-certified integration engineers, and former transit agency PM leads to understand the technical and contractual constraints on real-time fare rule sharing.
Build a scenario matrix across credential, device, service, and fare type, then validate against live agency documentation to confirm which failure modes are real and which are edge cases.
Other platforms hit the same wall.
The bottleneck is not the payment. It is the agency.
Two adjacent systems reveal the structural constraint Apple Wallet Transit faces: a global payments platform that solved metro ticketing but cannot do open-loop tap, and an open data standard that exists to surface fare data to Apple Maps but remains incomplete where riders need it most.
PhonePe is India's largest UPI payments platform, holding approximately 45% of UPI transaction volume by 2025. Under its Commute section, riders in Delhi (DMRC), Mumbai (Metro One), and Hyderabad (L&T Metro) can purchase a QR-code ticket, pay via UPI or card, and scan at the agency's AFC gate. IRCTC intercity rail booking works the same way, PhonePe as payment partner, agency as ticket issuer.
The wall is structural. PhonePe issues a QR ticket brokered through the agency's fare system, not a contactless tap at the turnstile. City buses remain fragmented: most lack QR-capable readers, so coverage falls to third-party apps or cash. A dead or confiscated phone invalidates the ticket with no recovery path. And every city requires its own agency integration.
Distribution and payment rails are necessary but not sufficient. Gate hardware and agency integration are the gating factor: for PhonePe, and for Apple. The difference is that Apple's NFC and Express Mode model is technically superior to QR at the gate. But the bottleneck is identical.
GTFS (General Transit Feed Specification) is the open standard through which transit agencies publish route and schedule data, the feed that powers Apple Maps transit directions. GTFS-Fares v2 adds machine-readable fare structure: fare products, rider categories (senior, student, Medicare), fare media types including contactless EMV acceptance, and transfer discount rules across agencies.
Apple Maps is a named consumer of GTFS-Fares v2. Where agencies publish it, Apple can surface the correct fare per payment medium before the rider reaches the gate. Production adopters as of mid-2026 include MBTA, the SF Bay Area MTC regional feed, TriMet, and Sound Transit. Fare capping is not yet fully modeled in the spec.
The data Apple needs to surface accurate fares exists in a standard Apple already consumes, but the standard is incomplete, and most agencies have not yet adopted the fare capping and reduced-fare eligibility modules. This is a spec gap Apple is positioned to help close from the consumer side.
The common finding: when a digital platform tries to simplify transit access, the bottleneck is always the agency side: what data they expose, what hardware they operate, what rules they can share in machine-readable form. TapFlow is designed to close this gap from Apple's side of the integration, without requiring agencies to redesign their fare infrastructure.
The wrong question has a clean answer.
The right question is harder.
Can the rider pay with their iPhone?
Does the rider have the right credential, on the right device, for the right service, with a clear path forward if something fails?
This reframes Wallet Transit from a payment acceptance problem into a transit fulfillment problem. The payment rail is excellent. What is missing is the orchestration layer that completes the rider's access intent end to end.
Wallet holds transit cards and payment cards. Riders are responsible for knowing which to use, when, and on which device. Documentation is the support layer.
Wallet knows the rider's transit context per city and network. It configures credentials, guides setup, surfaces fare constraints, and recovers gracefully when access fails.
Rider Need Mapped to Technology Mechanism
| Rider Need | Technology Mechanism | Current Gap | TapFlow Response |
|---|---|---|---|
| Board without choosing | Express Mode (ECP) + closed-loop transit card | Card clash; no guided setup; Express Mode buried in Settings | Transit Identity + Fulfilled Setup configure state before the gate |
| Pay the right fare | Open-loop EMV or agency reduced-fare card | Reduced fare requires separate enrollment outside Wallet | Fare and Eligibility Rules surface the enrollment gap during setup |
| Know which services work | GTFS-Fares v2 + partner metadata feed | Exclusions (commuter rail, ferry) documented only in static help articles | Service eligibility check surfaces before the gate, not after the decline |
| Keep fare cap continuity across devices | Hybrid / ABT account-based token | iPhone and Apple Watch are separate fare identities; cap resets on device switch | Device switch warning and cap continuity rules in TransitIdentity object |
| Board on a nearly dead phone | Express Mode power reserve (up to 5 hr, iPhone XS+) | Rider often does not know the phone is still usable until it is too late | Fulfilled Setup confirms Express Mode state and communicates power reserve behavior |
| Recover after a failed tap | Validator reason code + TSP signal | Generic decline message shown; ownership unclear; no next step | Access Recovery maps reason code to a specific, contextual next action |
What the product must do
Non-goals: TapFlow does not create a new global fare system, does not replace open-loop or closed-loop transit cards, does not force agencies to change their fare policies, and does not expose trip history beyond what riders explicitly permit. The solution is orchestration, not reinvention.
TapFlow
An integrated transit access orchestration framework for Apple Wallet. TapFlow connects rider intent, Wallet credentials, Express Mode configuration, device behavior, agency fare rules, service eligibility, fare caps, transfers, reduced fares, validators, partner launch operations, and post-launch telemetry into a system that completes the rider journey.
The correct credential, on the correct device, for the correct service, with a clear recovery path when access fails.
Transit Identity
A Wallet-level configuration object per city and network. Stores primary device, primary credential, Express Mode state, reduced fare status, supported services, fare cap tracking, and fallback credential.
Fulfilled Setup
Guided transit setup that completes system state, credential, Express Mode, device choice, reduced fare check, fare cap guidance, service confirmation. The rider does not just learn about readiness. Wallet makes the rider ready.
Fare and Eligibility Rules
A partner-provided rules layer: supported services, fare cap rules, transfer windows, tap-in/tap-out requirements, adult versus reduced fare support, pass validity, and service exclusions. Static at MVP, dynamic via API later.
Access Recovery
Contextual post-tap recovery. When a tap fails or produces an ambiguous outcome, Wallet shows a specific next action based on the available reason code or inferred service context, not a generic error message.
An internal PM and agency partner dashboard for launch and post-launch health. Tracks credential adds, Express Mode enablement rate, tap success and failure by reason, fare cap continuity breaks, device mix, reduced fare mismatch, support contacts, and incident status. This is the pit wall. The rider sees a simple tap. Apple and agency partners see where the race is being won or lost.
Five rider segments, current friction, TapFlow outcomes
Daily Commuter · Adult Fare
Long iPhone tenure, Express Mode likely on, rides subway and bus daily.
Usually works, but breaks after device upgrade, card reissue, or when commuter rail is added to the commute.
TransitIdentity persists across device changes. Service exclusion warning surfaces before the commuter rail gate, not at it.
Reduced Fare Rider
Eligible for student, senior, or low-income reduced fare. Enrollment is external to Wallet.
Apple Pay charges full adult fare. Rider does not know why or how to link their reduced fare program.
Fulfilled Setup detects the reduced fare gap and surfaces enrollment during setup, not after a confusing charge appears on their bank statement.
Apple Watch Primary Rider
Prefers to tap with Watch. Has same payment card on both iPhone and Watch.
May unknowingly create a separate fare cap identity from their iPhone tap history. OMNY's fare cap FAQ makes this explicit.
Device Continuity guidance explains the fare identity implication before the first Watch tap, not after a fare cap complaint.
New City Traveler
Apple Pay works in their home city. Arrives in a new city and assumes the same experience applies.
New city may require a different credential, a partner app, or may not support the same services.
Maps and Wallet surface city-specific credential guidance before the rider reaches the gate rather than after a failed tap and a confused search.
Commuter Rail Rider
Uses subway daily on Apple Pay. Adds commuter rail to their trip and assumes the same credential works.
Tap declined. Apple's own documentation lists commuter rail as excluded for several cities, including Boston. Rider finds this out at the gate.
Service exclusion warning before boarding, with guidance to use a CharlieCard or purchase a ticket at the station.
Five Directions Evaluated
Each concept was scored against seven weighted criteria. Scoring scale: 1 (weak) to 5 (strong). Criteria are weighted by their strategic importance to the transit PM role.
| Concept | C1 | C2 | C3 | C4 | C5 | C6 | C7 | Total |
|---|---|---|---|---|---|---|---|---|
| Transit Identity | 5 | 5 | 3 | 4 | 3 | 5 | 5 | 30 |
| Fulfilled Setup | 4 | 4 | 4 | 5 | 4 | 4 | 4 | 29 |
| Fare Rule Integration | 5 | 5 | 2 | 4 | 3 | 4 | 5 | 28 |
| Access Recovery | 5 | 4 | 3 | 4 | 4 | 4 | 5 | 29 |
| Launch Telemetry Cockpit | 4 | 4 | 4 | 5 | 4 | 5 | 5 | 31 |
TapFlow is not a single feature.
It is a system roadmap.
All five concepts scored strongly because they are different lenses on the same root problem. The right product is one that implements them in a phased sequence: starting with the highest-rider-impact, highest-Apple-differentiation modules and building toward deeper partner integration.
- Transit Identity v1
- Fulfilled Setup
- Access Recovery v1
- Launch Telemetry Cockpit v1
- Dynamic Fare Rule Integration via partner API
- Real-time fare cap status where supported
- Reduced fare account linking
- Station and reader issue intelligence
- Multi-rider support where agencies allow it
Fare Rule Integration scored highest on rider outcome and Apple differentiation but lowest on partner feasibility. It remains the long-term platform investment. The four MVP concepts are its buildable, measurable first steps.
TapFlow Pilot: Boston / MBTA
Boston is the right pilot market for three reasons. MBTA contactless scaled to 904,000 taps in its first full month and 3.17 million trips by July 2025, creating a meaningful measurement surface. Apple's own documentation lists Boston-specific exclusions (commuter rail, ferry, paratransit, reduced fare enrollment requirements), giving the pilot genuine product problems to solve. And my direct MBTA experience (transit APIs, real-time operations, geospatial systems, APC data) provides operational credibility with the partner.
Correct credential configured. Express Mode set. Service boundaries shown. One primary device chosen.
Wallet detects reduced fare gap during setup. Surfaces MBTA enrollment path. Shows full-fare warning if not linked.
Commuter Rail, Ferry, Paratransit surface as unsupported before the gate. Maps integration where feasible.
Warns when switching between iPhone and Watch in a way that may break fare cap continuity for MBTA's rules.
Contextual recovery after failed or ambiguous tap. If reason code is available: show specific action. If not: show ranked fallback: try card again, use alternate card, check service support, contact MBTA with ride reference.
Internal dashboard live on day one. Tracks setup conversion, Express Mode enablement, tap success/failure by reason, reduced fare enrollment rate, device mix, support contacts per 10,000 taps. This is the pit wall for the launch team.
Three critical flows in the system
Each diagram shows a different moment in the rider's race. Together they cover the full transit access lifecycle: setup, successful tap, and recovery.
TransitIdentity Data Object (MBTA Example)
// TransitIdentity — persisted per city / network { "market_id": "MBTA_BOSTON", "primary_device": "IPHONE", "primary_credential_type": "PAYMENT_CARD_TOKEN", "express_mode_status": "ENABLED", "reduced_fare_status": "NOT_LINKED", "supported_services": [ "SUBWAY", "BUS", "TROLLEY" ], "unsupported_services": [ "COMMUTER_RAIL", "FERRY", "PARATRANSIT" ], "last_health_check": "2026-06-25T09:14:00Z" }
TapOutcome Data Object
// TapOutcome — generated per tap event { "tap_status": "FAILED", "failure_reason": "SERVICE_NOT_SUPPORTED", "station_code": "MBTA_NORTH_STATION_CR", "device": "IPHONE", "credential_type": "PAYMENT_CARD_TOKEN", "recovery_action": "ADD_TRANSIT_CARD", "recovery_options": [ "ADD_CHARLIECARD", "BUY_TICKET_AT_STATION", "CONTACT_AGENCY_SUPPORT" ] }
Four Provisioning Paths
Adult Fare · Supported Service
Add Card: TapFlow evaluates city and network
Transit Identity confirmed: iPhone primary, Express Mode active, Subway supported
Rider taps iPhone at gate
Gate opens. Tap success logged to Telemetry Cockpit
Reduced Fare · Enrollment Gap
Rider adds payment card for MBTA
TapFlow detects no reduced fare link for MBTA program
Setup prompts: "Link card with MBTA reduced fare program for discounts"
Rider links or acknowledges full fare applies. TransitIdentity persisted
Unsupported Service · Commuter Rail
Rider selects commuter rail route in Maps or Wallet
TapFlow detects Commuter Rail excluded for MBTA Apple Pay
Warning shown before the station: "Commuter Rail requires CharlieCard or CharlieTicket"
Rider redirected to correct credential or ticket purchase
Failed Tap · Contextual Recovery
Rider taps. Decline signal received
TapFlow matches reason code to recovery action
Specific guidance shown, not a generic error state
Rider acts. If unresolved: MBTA contact with ride reference surfaced
Goals Across All Stakeholders
Successful Transit Access Completion Rate
The percentage of Wallet Transit rider attempts that complete the intended access path with the correct credential, correct fare eligibility, and no rider recovery required. Every other metric feeds this one.
- Board correctly the first time
- Avoid unexpected fare charges
- Know what to do when a tap fails
- Recover quickly without calling anyone
- Know before reaching the gate
- Increase transit adoption per market
- Reduce post-launch support contacts
- Strengthen Wallet as an access platform
- Improve launch quality across new cities
- Build a reusable launch infrastructure
- Improve launch confidence for agencies
- Better launch telemetry and health data
- Reduce agency support ticket volume
- Accurate representation of fare rules
- Aligned support messaging with Apple
Measurement Framework
Start narrow. Prove. Then expand.
RAID Log · Launch Risk Register
- Agency API integration timeline slips
- Validator reason code coverage inconsistent across MBTA
- Fraud adaptation to new tap patterns
- Regulatory variation in reduced fare data access
- MBTA will expose machine-readable service rules
- Partner API latency under 200ms at provisioning
- Riders have compatible devices for Express Mode
- MBTA provides reason codes for failed taps
- Reduced fare enrollment is outside Wallet's direct control
- Tap-in/tap-out signal not always available pre-launch
- Card clash requires physical intervention, not software alone
- Partner app dependency for some transit cards
- MBTA fare system vendor alignment
- Payment network tokenization support
- TSP integration for reason codes
- MBTA data access agreement for pilot
Three Key Experiments
Fulfilled Setup vs. Standard Setup
New transit riders in MBTA market, split between current Wallet setup flow and TapFlow fulfilled setup.
Riders who complete integrated setup are less likely to experience failed taps, incorrect fare charges, or support contacts in the first 30 days.
Express Mode enablement rate, first-week tap success, support contacts per 10,000 riders.
Tap success cannot decline. Privacy complaint rate protected.
Service Eligibility Warning Before the Gate
Riders who open Maps routes containing Commuter Rail services in the MBTA market.
Preemptive service warning before the station reduces gate-side failures and agency support contacts for excluded services versus showing no warning.
Decline rate for excluded services, support contacts in the “wrong service” category.
Warning must not add friction for riders using supported services.
Contextual Recovery vs. Generic Error State
Riders who experience a tap failure in the MBTA pilot market.
A specific, contextual recovery action reduces abandonment and support contacts versus the current generic error state shown after a failed tap.
Recovery completion rate, abandonment rate after failed tap, repeat failed tap rate.
Support contact rate cannot increase. Recovery must not surface in non-failure scenarios.
Fallbacks, degradation paths, and overrides
| Edge Case | Handling |
|---|---|
| Rider has no eligible payment card for open-loop | TapFlow routes to CharlieCard setup. Apple Pay open-loop path not presented as primary. |
| Device is new but rider has long Apple ID tenure | Apple ID and prior Wallet history compensate for low device-age signal. TransitIdentity migrates where feasible. |
| Rider recently changed payment card (reissue) | TransitIdentity detects credential change. Prompts re-confirmation of Express Mode for new token. |
| Agency does not support reason codes at launch | Recovery falls back to ranked context-based options rather than reason-specific guidance. Labeled accordingly to user. |
| SMS fallback required for transit card provisioning | Fulfilled Setup explains the step. Progress is saved. Recovery Assist surfaces options if provisioning fails. |
| Rider switches from iPhone primary to Watch mid-fare-cap period | TapFlow warns before first Watch tap that fare cap continuity may not transfer for MBTA. Rider acknowledges explicitly. |
| Partner rules API unavailable at setup time | TapFlow degrades gracefully to static rules from agency documentation. User is not blocked. Staleness is managed by refresh schedule. |
| Card clash: reader charges physical card not iPhone | Recovery Assist surfaces guidance: “Separate your physical cards from your phone before tapping.” ORCA documentation validates this approach. |
Where this proposal might be wrong
- Agency willingness and timeline to provide machine-readable fare rules
- Partner API coverage across all MBTA fare products and services
- Rider comfort with Wallet as the primary transit setup surface
- Technical feasibility of cross-device fare identity continuity at MVP
- Legal feasibility of reduced fare account linking across agencies
- Agency procurement and legal review cycles for data access agreements
- Validator reason code coverage and consistency across MBTA stations
- Regulatory variation in reduced fare eligibility data handling
- Operational change management required across agency and Apple support teams
- Time required to align marketing and communications across seven cross-functional teams
Without validation data, TapFlow remains a hypothesis. With it, the team can identify exactly where the orchestration layer creates leverage, and where the agency integration is the binding constraint.
If this were a real Apple project
Validate current transit access failure taxonomy with MBTA and agency support ticket data, starting with failed tap and wrong fare categories
Interview MBTA launch operations and fare technology leads to understand the biggest post-launch pain points and data-sharing constraints
Run rider intercepts at MBTA gates to observe credential selection and recovery behavior in real time, not in retrospective interviews
Map current Express Mode setup path in Wallet UX against where confusion and drop-off most commonly occur
Build a prototype of the fulfilled setup flow and test comprehension with eight to ten MBTA riders across fare types
Draft the partner rules API spec with a payments platform engineer, starting with the minimum viable schema for service eligibility and fare cap rules
Define the privacy-preserving signal contract with Legal and Privacy before any agency data access is discussed externally
Launch a controlled A/B experiment on setup flow with guardrail metrics active from day one, not added after the first anomaly is detected
Engage with the MobilityData GTFS-Fares v2 working group alongside Cal-ITP and Interline to accelerate the fare capping and reduced-fare eligibility modules, the spec gaps that currently prevent Wallet from surfacing accurate fares at setup for most agencies
Why MBTA matters personally: My work at MBTA exposed me to transit APIs, real-time operations, geospatial mapping, KPI workflows, and the operational reality that rider experience depends on data quality, agency workflows, and system reliability in ways that are not visible from the product surface. TapFlow extends that learning into Wallet Transit: a product is only simple for the rider when the underlying system is integrated enough to finish the race.
TapFlow is not a proposal to make transit documentation better.
It is a proposal to make the system do the work the rider currently has to do. Not more instructions. Not a help article. The system, configured correctly, warned proactively, recovered gracefully, so the rider can just ride.
Tap through every supported gate correctly, without knowing what fare system is running behind it.
Launch with confidence that Apple's experience reflects their fare rules, service scope, and support model accurately.
Strengthens Wallet as the transit access platform for riders around the world, not just the payment credential.
Do not make the rider become a fare system expert. Finish the race for them.