By moving fare calculation, account management and business logic from field devices into a central back office, account-based ticketing (ABT) gives transit agencies greater flexibility in how they manage fares, payments and the passenger exper
But that flexibility also changes the nature of an ABT implementation and integration project. Today’s ABT systems rarely operate in isolation. Validators, fare gates and ticket vending machines need to interact with the back office.
CRM, financial management, identity and analytics platforms may need access to fare and account data. And external services, from MaaS platforms to other mobility providers, add another layer to the ecosystem.
That means decisions made during design and procurement can have consequences far beyond the initial deployment – influencing operational complexity, costs, vendor dependencies and how easily the system can evolve over time.
So, what does successful ABT integration look like?
Over the coming weeks, we’ll take a closer look at the key considerations behind ABT system integration in our latest series “Inside ABT integration” – from open architectures and APIs to device integration, enterprise systems and procurement.
Because the goal isn’t simply to build a system that works today. It’s to create one that can evolve with the needs of tomorrow.
Want to dive deeper right away?
Our best practice paper, “Account-Based Ticketing System Integration in Public Transit”, explores these considerations in greater detail and provides practical guidance for planning and implementing an integrated ABT ecosystem.
DOWNLOAD the best Practice Paper