THE CHALLENGEA City Has Ten Mobility Apps and No Single Journey
A rider in a modern city juggles a bus app, a scooter app, a bike-share app, and a ride-hail app, each with its own account, payment, and map. Mobility-as-a-Service promises one app to plan, book, and pay across all of them, but delivering it means integrating live data and bookings from many independent operators, each with a different API, ticketing model, and settlement rule. The aggregation backend, the journey planner, the unified wallet, and the partner API layer make a single multi-modal journey real, shipped as a white-label app you can put your brand on.
One layer of the full Telematics and GPS Tracking platform, working closely with Telematics Software Development.
WHAT'S INCLUDED
The MaaS Platform, End to End
Multi-Modal Aggregation
Live supply from every mode is aggregated: public transport from GTFS and GTFS-Realtime feeds, shared scooters and bikes over GBFS, car-sharing and ride-hail over partner APIs. One normalized data model holds vehicles, routes, schedules, and availability across operators.
Journey Planning Engine
A multi-modal routing engine combines walking, transit, and shared vehicles into ranked journeys by time, cost, or carbon. It accounts for real-time transit delays and live scooter and bike availability so the plan a rider sees is the plan they can actually take.
Unified Payment Wallet
A single wallet pays across every mode. A rider tops up once, and the platform settles per trip with each operator behind the scenes through PCI-compliant processing, including pre-authorization, fare capping, and subscription passes.
Partner API Layer
Inbound and outbound APIs connect operators to the platform: availability and booking in, settlement and reporting out. New operators onboard against a documented API and a sandbox rather than a bespoke integration each time.
White-Label Apps
The rider app ships on iOS and Android plus a web app, all themeable to your brand. One codebase, configurable modes, payment options, and regions, so a transit authority or operator can launch its own MaaS app without building from scratch.
Operator and Authority Console
A back-office console for the platform owner covers partner onboarding, fare and policy configuration, settlement reports, and usage analytics across modes. A transit authority gets the demand and modal-split data it needs to plan service.
ONE JOURNEY, MANY MODES
Plan, Book, Pay, Travel
The point of MaaS is that the rider stops thinking about which operator runs which vehicle. They enter a destination and get a door-to-door plan that may use a scooter, a train, and a short walk, booked and paid in one flow. The platform makes that single journey feel like one product.
One Plan Across Operators
The journey planner combines a nearby scooter, a metro leg, and a final walk into one ranked option, with live availability and live transit delays folded in so the route holds up in the real world.
One Booking
A single confirmation reserves the scooter and issues the transit ticket through partner APIs. The rider unlocks the scooter and taps through the gate from the same app, with no separate accounts.
One Payment
The wallet pays each leg and settles with each operator behind the scenes. The rider sees one receipt for the whole journey, and the platform handles the splits and reconciliation.
HOW IT WORKS
Feeds, Services, Apps
Ingestion and Normalization
GTFS, GTFS-Realtime, GBFS, and partner APIs are ingested into a normalized mobility model. A live cache holds vehicle and schedule state so the journey planner and app read fresh data without hammering each operator.
Core Services
A microservice backend runs the routing engine, the booking orchestrator, the wallet and settlement, and the partner gateway. Bookings are transactional across operators so a rider is never charged for a leg that did not confirm.
Apps and APIs
The white-label rider apps and the operator console sit on a documented API. Partners integrate against a sandbox, and the platform exposes analytics and settlement feeds back to operators and the authority.
STANDARDS AND COMPLIANCE
Open Standards, Settled Money
Open Mobility Standards
Built on GTFS and GTFS-Realtime for transit, GBFS for shared micromobility, and TOMP-API patterns for MaaS interoperability, so onboarding a new operator is configuration rather than a rebuild.
Payment and Settlement
Payment runs through PCI-compliant processors, and the settlement engine produces auditable splits per operator. Refunds, fare caps, and subscription passes all reconcile against the trip ledger.
Data Privacy and Accessibility
Rider data handling follows GDPR and local privacy rules, with consent and data minimization built in. The apps follow accessibility guidelines so the service works for every rider in the city.
FAQ
Common Questions
What modes can a MaaS platform aggregate?
Public transport over GTFS and GTFS-Realtime, shared scooters and bikes over GBFS, and car-sharing and ride-hail over partner APIs. The platform holds them in one normalized model so the journey planner and wallet treat every mode the same way.
How does the unified payment wallet settle with operators?
A rider tops up or pays once, and the settlement engine splits each journey across the operators that served it, settling behind the scenes through PCI-compliant processing. Every split is auditable against the trip ledger, with fare caps and passes handled centrally.
How long does it take to onboard a new operator?
Because the platform builds on open standards and a documented partner API with a sandbox, an operator that already publishes GBFS or a standard booking API onboards in days, not months. Bespoke integrations are reserved for legacy systems without a standard interface.
Is the rider app white-label?
Yes. iOS, Android, and web apps come from one codebase, themeable to your brand, with configurable modes, payment options, and regions. A transit authority or operator can launch its own branded MaaS app without building from scratch.
Does the journey planner use real-time data?
Yes. The routing engine folds in GTFS-Realtime transit delays and live GBFS vehicle availability, so the journeys a rider sees account for the actual state of the network rather than a static timetable.
Can an existing scooter or bike-share fleet be integrated?
Yes. If your fleet exposes GBFS or a booking API it connects as a mode in the platform. The scooter and bike-share systems themselves can also be built, so the fleet and the MaaS layer can be delivered together if you need both.
Ready to Build Your MaaS Platform?
Share the modes you want to aggregate, your payment model, and your city or region to get a tailored approach across the aggregation backend, the journey planner, and the white-label apps.
Schedule a Free Consultation