Account-Based Ticketing: A Guide to Contactless Public Transport and Integrated Fares

25/08/2026

Account-based ticketing changes public transport by moving the fare from a physical ticket into a central digital system. This guide explains how contactless travel, fare capping, multi-operator journeys, passenger accounts and payment processing work, and what cities need to consider before replacing conventional tickets.

What you will learn

how account-based ticketing differs from traditional tickets and smartcards;
how contactless bank cards and transport cards can operate within the same system;
how fare capping calculates the best price after travel;
why integrating several operators involves commercial as well as technical work;
how cities can retain access for people without bank cards or smartphones;
which privacy, cybersecurity and procurement risks need attention.

Public transport has become much easier to plan than it was twenty years ago. A passenger can compare routes across trains, buses and metro services on one phone, see delays in real time and receive directions for each transfer. Paying for the same journey can still require an understanding of zones, ticket types, individual operators and rules that vary between services.

Account-based ticketing is designed to remove much of that work from the passenger.

Instead of buying a specific travel product before the journey, a passenger identifies themselves to the transport system using a bank card, smartphone, smartwatch or dedicated travel card. The back-office system records the journeys and calculates what the passenger should pay.

London provides the most mature large-scale example, but similar systems are appearing across European and international transport networks as authorities replace ageing ticketing infrastructure.

The technology is often described as contactless payment, although payment is only one part of it. The larger change concerns where the fare rules sit and when the final price is determined.

What is account-based ticketing?

Traditional ticketing places the travel entitlement on the ticket itself.

A paper ticket might entitle its holder to one journey between two stations. A monthly pass gives unlimited travel within defined zones. An older smartcard can store prepaid value or a particular travel product.

Account-based ticketing stores the travel information in a central system instead.

The card or device presented at the gate mainly tells the system which account or payment credential made the journey.

The back office can then evaluate several journeys together.

That makes it possible to apply rules such as:

daily fare caps;
weekly fare caps;
transfers between operators;
peak and off-peak pricing;
concessionary rates;
zone combinations;
maximum journey charges;
multimodal discounts.

The passenger no longer has to predict the correct product before travelling.

Contactless payment and account-based ticketing are not the same thing

The two terms are often used interchangeably.

Contactless describes how the passenger interacts with a reader.

Account-based ticketing describes how the system calculates and manages the fare.

A city can use contactless cards without having a sophisticated account-based fare system, while a dedicated transport card can operate through an account-based back office without using an ordinary bank card.

Understanding the difference becomes useful when a transport authority starts designing a new system because payment technology can change much faster than the underlying fare architecture.

Open-loop and closed-loop ticketing

Most modern systems use one or both of two broad approaches.

Open-loop systems

Passengers use an ordinary bank card or digital wallet.

The transport authority accepts a credential that already exists rather than issuing its own card to every passenger.

Open-loop travel works particularly well for:

occasional travellers;
tourists;
commuters who do not need a special concession;
passengers who prefer not to maintain a separate travel balance.

A visitor can arrive in a city and begin travelling without understanding how to buy a local card.

Closed-loop systems

The transport authority issues its own travel card or credential.

The passenger may load money onto the card or connect it with a central account.

Closed-loop systems remain valuable because public transport needs to serve people who cannot or do not want to use a bank card.

They also make it easier to manage some concessionary fares.

The strongest networks often retain both rather than forcing every passenger into one payment method.

How fare capping works

Fare capping is one of the most useful consequences of account-based ticketing.

Under a conventional fare system, passengers may have to decide before travelling whether a daily pass will cost less than several individual journeys.

That requires predicting the day.

With capping, the passenger simply travels.

Imagine that each journey costs €2.20 and the daily maximum is €7.50. The system records each journey until the passenger reaches the maximum. Further eligible trips no longer increase the day’s charge.

Real transport networks use more complicated calculations because zones, peak periods and different modes can affect the price.

The principle remains the same: the passenger receives the benefit of a pass without having to buy the correct one in advance.

Weekly caps can serve commuters whose schedules no longer fit a traditional five-day working week particularly well.

Someone travelling to an office three days one week and five the next does not have to decide whether a monthly pass makes financial sense every time their pattern changes.

The infrastructure behind one tap

A contactless transaction at a station gate can take less than a second.

The system behind it contains several layers.

Reader or validator

The physical device recognises the passenger’s card or phone.

Communications network

Transaction data needs to reach the back office reliably.

Tokenisation and payment processing

Bank-card information is normally handled through secure payment infrastructure rather than stored casually inside the transport system.

Passenger or credential account

The system associates journeys with the correct credential.

Fare engine

Software calculates the price according to zones, transfers, time and caps.

Revenue clearing

Where several operators participate, the system determines how the money should be divided.

Customer service

Passengers need to see journeys, correct mistakes and challenge charges.

A city procurement programme that concentrates mainly on validators risks treating the visible hardware as the project when most long-term complexity sits elsewhere.

Multi-operator journeys are the harder problem

Many urban regions contain several transport organisations.

A passenger may begin on a regional railway, transfer to a city metro and finish on a municipal bus.

From the passenger’s perspective, it is one journey.

Institutionally, three operators may have provided it.

Integrated ticketing therefore requires agreements about:

revenue distribution;
transfer discounts;
concessions;
refund responsibility;
customer support;
settlement timing;
fraud losses;
data ownership.

Technology can calculate the fare once those rules exist.

It cannot decide how independent operators should divide revenue.

Regional governance consequently matters just as much as reader technology.

Public transport should not require a bank account

Contactless bank cards make travel easier for millions of people, but cities should be cautious about turning possession of a payment card into a condition for using essential public infrastructure.

Some passengers rely on cash.

Children may not have bank cards.

Visitors can experience payment failures.

Others may use prepaid financial products or require concessionary travel.

A comprehensive system can retain options such as:

reloadable travel cards;
cash top-up locations;
ticket machines;
anonymous cards;
concessionary credentials.

Moving the fare calculation into an account does not require eliminating every physical route into the system.

Concessionary fares

Discounts for children, students, older passengers or people with disabilities create another design problem.

An ordinary bank card does not inherently tell the fare engine that its user qualifies for a concession.

A city can solve this by linking the payment credential with a verified passenger account or issuing a dedicated card.

The verification process needs to remain simple enough that eligibility does not become an administrative barrier.

Ticketing data can improve transport planning

Account-based ticketing generates a detailed picture of journeys.

Transport authorities can see where people transfer, which routes are frequently combined and how demand changes during the day.

That information can support decisions about:

service frequency;
station capacity;
timetable coordination;
transfer design;
fare boundaries.

Suppose thousands of passengers consistently make a bus-to-rail connection within a six-minute window and regularly miss it because the bus timetable arrives two minutes too late.

Fare and journey data can identify the problem more clearly than a general passenger survey.

Privacy needs deliberate design

The same journey record that improves network planning can reveal sensitive information about individuals.

Repeated travel data may indicate where someone lives, works or spends time.

Cities therefore need to distinguish between information required to calculate the fare and information retained for longer-term analysis.

Aggregated or appropriately anonymised data can often answer planning questions without giving analysts access to identifiable travel histories.

Retention periods, access rights and data sharing should be established before the system launches rather than added after passenger concerns arise.

Cybersecurity

A ticketing system combines several attractive targets:

payment credentials;
travel data;
passenger accounts;
transport infrastructure;
revenue flows.

Attackers do not need to compromise the whole transport network to create operational disruption.

A failure in authentication, back-office settlement or reader connectivity can affect passengers at scale.

Authorities should therefore examine:

segmentation between payment and operational systems;
encryption;
access permissions;
incident response;
offline operation;
supplier security;
software update procedures.

Operational resilience deserves particular attention because transport cannot simply stop when a central system becomes temporarily unavailable.

What happens when the network goes offline?

A fully connected system sounds ideal until communications fail.

Readers may therefore need a controlled offline mode that allows known credentials to continue travelling while transactions queue locally.

The authority then accepts some temporary payment risk in exchange for keeping the network moving.

Designing that trade-off requires decisions about:

maximum offline duration;
blocked-card lists;
transaction limits;
reconciliation once connectivity returns.

A transport system cannot apply the same failure rules as an ordinary online shop because denying every uncertain transaction could strand thousands of passengers.

Payment failures

Transit payments introduce another peculiarity.

Passengers may travel before the payment system knows with complete certainty that the final charge will settle.

A card might later be declined because of insufficient funds or another banking restriction.

Operators need policies governing:

retry attempts;
negative balances;
temporary card blocking;
debt recovery;
passenger appeals.

Aggressive enforcement can create disproportionate inconvenience over a small failed fare, while weak controls make repeated non-payment easier.

Procurement and vendor lock-in

Account-based ticketing can operate for decades.

Cities should therefore examine how easily they can:

replace individual suppliers;
add new transport operators;
change fare rules;
integrate another payment method;
export passenger and transaction data;
move to another back-office provider.

A proprietary system may appear efficient at launch and become expensive when every future change requires the original supplier.

Open interfaces and clearly defined data ownership can preserve more flexibility.

The connection with Mobility-as-a-Service

Account-based fares can become part of a wider multimodal system.

A journey planner could combine:

train;
metro;
bus;
bike share;
ferry;
demand-responsive transport.

The passenger might eventually receive one journey calculation and one combined payment rather than maintaining separate accounts for every service.

Commercial integration becomes considerably harder once private operators enter the system, because fare rules and revenue sharing have to work across businesses with different economics.

The technical possibility already exists.

Institutional cooperation will determine how quickly it becomes ordinary.

Main implementation risks

Excluding passengers

Risk: cashless design makes travel harder for people without conventional payment cards.

Practical response: maintain alternative credentials and accessible top-up channels.

Fare opacity

Risk: passengers cannot understand why they were charged a particular amount.

Practical response: provide clear journey histories and explain cap calculations.

Vendor dependence

Risk: one supplier controls essential architecture for years.

Practical response: procure around documented interfaces and data portability.

System outage

Risk: a central failure disrupts an entire network.

Practical response: design offline operation and degraded service modes.

Data misuse

Risk: travel histories are retained or shared unnecessarily.

Practical response: minimise identifiable data and establish clear retention rules.

Operator disagreement

Risk: technically integrated travel remains commercially fragmented.

Practical response: agree revenue and customer-service rules before implementation.

Payment fraud

Risk: invalid cards or repeated failed transactions create losses.

Practical response: use risk controls without making legitimate travel unnecessarily difficult.

What cities should decide before implementation

Technology selection should follow several policy decisions.

Transport authorities should first determine:

Which modes need to work together?
Which fare products should disappear?
Which concessionary groups must be supported?
Is cash still accepted?
How should revenue be shared?
What data genuinely needs to be retained?
Who owns the customer relationship?
How will the network operate when connectivity fails?
Can another supplier take over later?
Which future modes should be easy to add?

The answers determine the system architecture.

What is changing

Public transport ticketing is moving towards regional rather than purely municipal integration because passenger journeys rarely stop at administrative boundaries.

Fare structures are also becoming more flexible as hybrid work weakens the logic of conventional commuter passes.

Meanwhile, phones and wearables are making the credential itself less important. The passenger increasingly cares only that the system recognises them and calculates the correct fare.

The logical endpoint is a transport network in which payment becomes almost invisible.

Passengers should be able to choose the journey that works without first learning which institution operates each section.

Conclusion

Account-based ticketing transfers complexity from passengers into transport infrastructure.

That is why the strongest systems feel simple at the gate despite requiring sophisticated fare engines, payment processing and agreements between operators behind the scenes.

Cities gain the most when they treat the project as transport integration rather than merely contactless payment. The reader is the easy part. Designing fares, protecting access, governing data and deciding how organisations share revenue will determine whether the system actually improves public transport.