A mobility as a service platform is software that sits on top of a city’s transport network and puts every mode behind one login, one map and one payment. When someone searches how mobility as a service platforms work, the short version is this: a rider tells the app where they are going, the app pulls live data from each operator, stitches the pieces into a single itinerary, books what can be booked, takes one charge, and then splits the money back out to the operators who provided the trip.
That last part — the settlement — is where most of the difficulty hides. Planning a trip across a bus, a train and a scooter is straightforward compared with making four different companies agree on how the fare should be divided. Understanding the machinery means looking at both halves.
Table of Contents
- What is a mobility as a service platform?
- What transport modes does a MaaS platform bring together?
- How does the platform connect different transport services?
- The layers that have to connect
- A trip from a suburban street to a downtown office
- What happens from search to arrival?
- Why do MaaS platforms need open data and shared standards?
- The standards that do most of the work
- Who has to agree to publish what
- How do users pay for a multimodal trip?
- The ticketing models, from cheapest to hardest
- How the money actually moves
- How do MaaS platforms handle real-time changes?
- Who operates a MaaS platform?
- What is actually running today
- What are the main benefits and challenges?
- Frequently Asked Questions
- Is mobility as a service the same as a public transport app?
- Do users need one account for every transport operator?
- How can a city start a mobility as a service pilot?
- What happens if a service is delayed or cancelled?
- Are mobility as a service platforms suitable for smaller cities?
- How do platforms make money while keeping the service accessible?
- Conclusion
What is a mobility as a service platform?
Mobility as a service (MaaS) is a digital layer that combines public and private transport services in a defined area so a rider can plan, book and pay for a whole trip through a single interface and account. The platform itself usually owns no vehicles. It connects the ones that already exist and handles the pieces none of them wants to handle alone.
A rider in Berlin might open Jelbi, see a tram, a bike-share bike and a taxi in one search box, and pay once. A rider in Pittsburgh opens the Transit app to plan a bus trip, reserve a bike-share bike and start a car-share booking. Neither platform drives anything. Both change how the underlying services feel.
What transport modes does a MaaS platform bring together?
Platforms usually group modes into four families, and the difference matters because each one integrates differently.
- Public transit — bus, tram, metro and regional rail. Schedules come from published feeds; booking is rarely needed because you just board.
- Shared vehicles — car-share and van-share. These need a real reservation, a vehicle unlock code and a handover process, so the integration is transactional rather than informational.
- Micro-mobility — bike-share and scooter-share. Availability comes from a live feed of station and vehicle positions, and unlocking happens through a code or a Bluetooth handshake.
- On-demand rides — taxi, ride-hailing and demand-responsive transit. The platform brokers a dispatch request and waits for an estimated arrival, a fare estimate and a driver assignment.
The harder a mode is to book, the more the platform depends on that operator’s system being genuinely open. A bus route added to a journey planner is a data problem. A car-share booking is a contract between two systems.
That is also the line between MaaS and an ordinary transit app. A transit app shows one network’s buses and sells that network’s tickets. A mobility as a service platform reaches across operators, and in the better examples it can reserve and pay for more than one of them.
How does the platform connect different transport services?
Connection happens through agreed interfaces, not through anyone hand-writing every schedule. Each operator exposes part of its system, and a middleware layer in the middle translates between them.
The layers that have to connect
Five connections do most of the work, and a platform is only as good as the weakest one.
- Data connections — static schedules, live vehicle positions and service alerts, all read through published formats.
- Booking connections — APIs that reserve a seat, a car or a bike, and confirm or cancel it.
- Identity connections — one account that the rider signs into once, linked behind the scenes to each operator’s customer record.
- Ticketing connections — barcodes and QR codes the inspector recognises, sometimes just the platform’s own code accepted at every gate.
- Payment connections — a stored balance or card on file, a wallet, and a ledger that records what each leg owes.
Identity is the piece riders feel least and operators fear most. Once a platform holds a single user profile, that profile becomes the customer record for a dozen services, which raises data-protection questions that a transit app never had to answer.
A trip from a suburban street to a downtown office
Picture a rider leaving a residential neighbourhood eight kilometres from the city centre at 7:40 in the morning. They open the app and set the destination as an office tower.
The planner already holds the bus timetable for that morning. It checks which services actually run at that hour, then looks at the first-mile options: no shared bike stands within a few hundred metres, but a car-share vehicle is parked on the same street and can be unlocked immediately.
It assembles the trip: car-share for four kilometres, then a tram for three stops, then a walk of four minutes. Because the last leg is on foot and the first leg is unreserved, only the car-share booking needs a live call to an operator’s system. The planner returns one arrival time, one total fare and one tap-to-pay option.
Every leg of that answer came from somewhere else. The tram minutes are a published schedule, the car location is a live feed, the fare is a rule the platform computed and the operator confirmed. Nothing here is guesswork, which is exactly why the platform is worth building.
What happens from search to arrival?
The rider-visible sequence is short. The back-office sequence behind it is not.
- Sign-up — the rider creates an account, verifies an email or phone number, adds a payment method and picks accessibility preferences such as step-free routing or a wheelchair-capable vehicle.
- Trip request — origin, destination and constraints go in. Constraints can mean arrive by a certain time, avoid a transfer, keep the cost under a cap or use only low-emission modes.
- Mode aggregation — the planner combines timetables with live positions and searches combinations rather than a single network, scoring options on time, cost, transfers and walking distance.
- Booking and inventory — anything that needs reserving is requested from the operator’s system. A bus seat usually needs nothing beyond an advance ticket; a shared car holds a reservation for a few minutes while the rider walks to it.
- Payment authorisation — the platform estimates the fare, places a hold or stores the charge against a balance, and issues a single ticket or code covering the whole trip.
- Live execution — as the rider travels, the platform tracks each leg and watches the next one. Alerts fire when a connection is at risk.
- Arrival and completion — boarding closes the leg, the fare is confirmed rather than estimated, and the final receipt shows the breakdown by operator.
- Settlement and analysis — the ledger pays each operator its share, and the data goes to the city as anonymised trip records.
As a plain flow it reads: rider app, then planner, then mode aggregation, then operator feeds and booking systems, then payment and settlement, then data back to the city and back into the planner as better predictions.
That last arrow is the quiet advantage of a platform with real volume. Every completed trip teaches the system something about where demand actually goes, and cities rarely have that picture anywhere else.
Why do MaaS platforms need open data and shared standards?
Because without shared formats, every connection is a custom integration, and custom integrations do not scale past a pilot. Standards are what turn a bespoke project into infrastructure.
The standards that do most of the work
Four matter most, and any city team planning a build will meet all of them in the first month.
- GTFS — the schedule format transit agencies publish. One text file describes every route, stop, trip and fare rule. It is the baseline input for almost every journey planner.
- GTFS-Realtime — the live companion to GTFS, carrying vehicle positions, trip updates and service alerts. A planner with only GTFS is planning against a timetable nobody is running.
- GBFS — the General Bikeshare Feed Specification, which publishes station status and free bike availability. It is the de facto standard for shared bikes and scooters.
- MaaS API — a shared interface specification for discovery, booking and payment, developed in Europe and now shaped by EU Delegated Regulation 2023/1226, which set interoperability requirements for mobility data spaces.
Underneath all four sits a plainer requirement: a common identifier. If a bus stop, a shared bike and a street address cannot be described in the same coordinate system with the same names, no planner can assemble them into one trip.
Who has to agree to publish what
Transit agencies and cities usually publish the schedules, since the data is already public. Shared mobility and ride-hailing operators publish their live feeds, usually under contract because the underlying data is commercially sensitive. The city sets the terms, the agency validates the content and the platform consumes both.
The practical failure mode is not a refusal, it is silence. An agency that stops updating its feed leaves a planner quietly wrong for months, and riders lose trust faster than they forgive a missing feature.
How do users pay for a multimodal trip?
Payment is where MaaS is most often overpromised. One app does not automatically mean one bill unless the operators have agreed to settle, and that agreement is legal and commercial work rather than a technical setting.
The ticketing models, from cheapest to hardest
| Model | How it works | What it needs |
|---|---|---|
| Contactless and stored value | Rider taps a card or phone at each gate and pays per leg | Acceptance of open-loop payments at every reader |
| Pay-as-you-go | One account records every trip and bills at the end of a period | Usage records from every operator, sent to a common ledger |
| Fare capping | Daily or monthly spend stops at a ceiling, regardless of how many trips are taken | A shared rule set and a fare engine that can reconcile across networks |
| Mobility account or wallet | Rider holds stored value that any integrated service can draw down | Money-transmission handling and rules on unredeemed balances |
| Subscription bundle | A monthly fee covers a set of modes or a fixed amount of travel | Forward revenue commitment between platform and operators |
| True integrated fare | One ticket covers a defined set of legs across operators at one price | Political agreement on who gives up revenue and who absorbs variance |
Contactless and stored value are the easiest because each operator still gets paid directly. A true integrated fare is the hardest because someone has to give up a share of the fare in exchange for a single ticket, and that conversation usually takes longer than the software.
How the money actually moves
When a trip spans operators, the platform holds the rider’s money briefly and records what each participant is owed. Each settlement cycle, it pays the transit agency its fare, the operator its per-trip or revenue-share amount, and possibly a platform fee.
Refunds are the messy part. If a rider pays one charge and half the trip never happens, the platform needs rules in advance: does the operator absorb the cost, does the rider get a partial refund automatically, and what happens when a delay was not the platform’s fault?
Riders interviewed in user studies repeatedly named transparent pricing before booking as a trust signal, and buried fees as a reason they stopped using a platform. Pricing that cannot be shown before the tap is a product bug, even when the arithmetic is defensible.
How do MaaS platforms handle real-time changes?
Real-time handling has two halves: knowing what is happening, and deciding what to tell the rider about it.
The knowing half comes from feeds. Live vehicle positions, predicted arrivals, service alerts and out-of-service notices arrive as structured messages, and the platform merges them with the planned itinerary. A tram delayed by four minutes is a simple substitution. A cancelled connection after the last scheduled service of the evening is a different problem entirely, and it usually needs a fallback the planner was never configured to offer.
The deciding half is where platforms differ most. A rule-based system re-plans when a leg slips. A predictive system estimates the delay before it is reported, which sounds better and is often worse, because a confident wrong estimate erodes trust faster than silence.
Good operators keep a human decision on the important calls. A missed last train is not a re-routing problem, it is a service-level problem that a person and a duty manager should own. Platforms that automate those decisions end up optimising for on-time performance metrics while riders remember the one night they were stranded.
Who operates a MaaS platform?
Nobody runs MaaS in the abstract. Someone owns the contract, the data rights, the app relationship with the rider and the money, and there are four common arrangements.
- Public-led — a city or transit agency owns the platform and contracts operators into it. Best for control and equity, slowest to build.
- Operator-led — one transport operator builds the front end and invites others in. Fast, but naturally biased toward the host’s own network.
- Platform-led — a private company runs the app and handles settlement, with operators supplying services. Whim, built by MaaS Global, worked this way across several European cities before the company restructured.
- Hybrid or federated — a neutral body runs identity, payment and data standards while operators keep their own front ends. Increasingly common where regulation pushes interoperability.
What is actually running today
| Platform | Market | Modes | Payment model | Governance |
|---|---|---|---|---|
| Transit app | Pittsburgh and other US cities | Transit, plus partner bike-share and car-share services | Transit fare plus per-trip service charges | Transit agency led |
| Jelbi | Berlin | Transit, bike-share, car-share, taxi and on-demand buses | Monthly pass covering included services, pay-as-you-go for extras | Platform led with municipal contracts |
| Moovit | Used worldwide by agencies and cities | Multimodal planning, ticketing, with city-specific partner modes | Varies by city; mostly agency ticketing | Supplier to public authorities |
| Whim | Helsinki, Birmingham and other pilots | Transit, car-share, taxi, rental bikes | Subscription and pay-as-you-go, per-ride pricing | Private operator, restructured after its expansion stalled |
The pattern across these programs is that the marketing promise and the operating reality have drifted apart. In Pittsburgh, the program drew around 63,000 unique monthly active users and millions of sessions, yet ride-hailing and scooters still lived in their own apps and buses were the only mode with in-app payment. Riders got one front door for planning and a collection of doors for everything else.
What are the main benefits and challenges?
The benefits are real, and they are unevenly distributed.
- Less friction between modes — the first and last mile gap is where transit trips die, and a feeder service is the cheapest way to close it.
- One payment and one receipt — riders value this more than any feature in the app, and it is the clearest thing to deliver.
- Better data for the city — anonymised trip records show demand that never appears in a farebox, because most riders pay nothing.
- A testbed for demand-responsive service — platforms give cities a way to try on-demand transport on specific corridors before committing vehicles.
The challenges are just as concrete.
- Integration cost — each operator’s system is different, and the work does not shrink. Every new partner is another contract and another test cycle.
- Commercial sustainability — forward revenue, thin per-trip fees and public funding rarely agree on who pays. Operators that cannot see a business case withdraw, and riders notice when a mode silently disappears from the app.
- Equity outcomes are unproven — in Pittsburgh, only 0.1 percent of Spin users used the accessible Spin Access programme marketed to underserved areas, even as disability groups formally objected to the pilot. Usage skewed young, and only about 7 percent of scooter trips connected to transit, which weakens the modal shift case considerably.
- Regulation — local rules on dockless vehicles, curb space and vehicle age push operators out. In Pittsburgh, one scooter operator withdrew citing Pennsylvania regulation and aging equipment.
- The digital divide — a smartphone-and-card-only platform excludes riders without a bank account or a data plan. Discounts help at the margin and do not solve the structural problem.
- Street-level side effects — dockless scooters left in awkward places made travel harder for blind and mobility-impaired residents. No software fixes a pavement problem.
History offers a warning too. The 2009 Gothenburg subscription pilot was competently executed and still collapsed, largely because it lacked government backing and ran into trouble reselling third-party tickets. Technical success does not carry a business model on its own.
Frequently Asked Questions
Is mobility as a service the same as a public transport app?
No. A transit app shows one network’s routes and sells that network’s tickets. A mobility as a service platform reaches across operators, combining transit with shared bikes, shared cars, taxis and on-demand rides under one account. The test is whether a rider can plan and pay for a trip that crosses more than one operator through the same interface. Where an app adds partner services to its map but still sends riders to other apps to book or pay, it is a journey planner with partnerships, not full MaaS.
Do users need one account for every transport operator?
Ideally not. That is the point of a platform. In practice a rider signs up once, and the platform links that profile to each operator’s customer record behind the scenes. Some services still require a direct agreement, for example a car-share membership with a credit check, or a transit card registered in the passenger’s name. Those checks cannot be skipped, which is why some modes appear in a MaaS app for planning but still need a separate booking step to be used.
How can a city start a mobility as a service pilot?
Start with one corridor or one neighbourhood and a single journey people already struggle to make. Map the operators on that route, confirm they publish usable schedules and live feeds, and pick the narrowest goal you can measure, usually combining pay-as-you-go payment for transit with one feeder mode. Agree the revenue split and the data rights in writing before building anything. Set an end date and a success measure in advance, because pilots without a decision point tend to linger indefinitely.
What happens if a service is delayed or cancelled?
The platform compares the live feed against the itinerary and warns the rider when a connection is at risk, then offers a revised plan. Re-routing is easy when a later bus or an alternative mode exists and hard when the rider has missed the last service of the night. That case needs a human decision and a duty manager, not an algorithm. Riders also expect an automatic partial refund when a booked leg never happens, which means the refund rules have to be agreed with each operator in advance.
Are mobility as a service platforms suitable for smaller cities?
Often more so than large ones, because a small city usually has one transit operator, a handful of shared bike providers and short distances, which makes the integration problem small. The harder issue is volume. With few daily trips, subscription bundles and forward revenue models rarely pencil out, so pay-as-you-go and fare capping are more realistic. A small city can also pilot faster, since fewer partners means fewer contracts, which is why several mid-sized municipalities have shipped integrated apps ahead of major ones.
How do platforms make money while keeping the service accessible?
The usual sources are a commission on partner transactions, a monthly subscription in some markets, and public funding for the equity and coverage parts that no fare covers. Low-income discounts are typically funded separately from fares so they do not come out of operator revenue. Cities also buy the data and the integration itself as a public good. The tension is real: money taken from riders reduces access, so the more the platform earns from partners and public contracts, the more it can keep rider pricing simple.
Conclusion
A mobility as a service platform is an integration layer, not a new transport system. It works because scheduled data, live feeds, booking APIs, one identity and one payment ledger are wired together in a way that lets a rider treat a whole trip as a single object.
The practical first step is smaller than most plans assume. Pick one high-value journey that people already make badly, list the operators it crosses, and check what each of them publishes today. If the data is not open, no amount of app development fixes that, and the project will not get past its first budget review.
