Transit fare systems: account-based ticketing and open payments

Reference article · 5 min read

Fare collection is one of the few public agency systems that every rider touches every day. It is also a payments system and a source of records subject to public records and privacy law. Agencies replacing aging fareboxes and first generation smart cards are making decisions that shape operations for a decade: where fare rules are calculated, what a rider can tap, and how a neighboring agency joins later without a second procurement.

Vendors use the same words for different designs. Account-based ticketing describes where fare logic runs; open payments describes what media the system accepts. They are separate decisions, and an agency can buy one without the other.

Card-based and account-based designs

In a card-based system, stored value and fare rules live on the media itself. The reader validates locally and keeps working without connectivity, but a fare policy change has to reach every card and every device, and a lost card usually means lost value.

In an account-based system, the card, phone, or bank card is only an identifier. Balances, passes, discounts, and rules live in a back office that computes the fare after the tap. That is what makes fare capping, autoload, and new media types practical without reissuing anything.

Account-based does not mean always connected. Require a defined offline mode: how long validators accept taps without a back office response, what deny list they carry, and who absorbs uncollected fares.

Open payments with contactless bank cards

Open payments means accepting contactless credit and debit cards and phone wallets directly at the validator. The transit flow differs from retail: the card is checked against risk rules or authorized for a nominal amount, taps are aggregated, and the fare is charged later. That deferral enables capping across a day or week, and it is where uncollected fare risk sits.

Merchant of record. Decide whether the agency or the vendor holds the merchant relationship. It drives who receives settlement, who handles disputes, and who negotiates processing fees.
PCI DSS scope. Ask for a responsibility matrix and a current attestation covering validators, back office, and any hosted payment page. Encryption and tokenization reduce what falls inside your environment but do not remove the obligation to validate.
Per-transaction economics. Small fares carry proportionally high processing cost. Model aggregation rules and fees against your own fare mix before signing.
An addition, not a replacement. Riders who are minors, unbanked, or enrolled in discount programs still need agency-issued media.

Fare capping and discount administration

Fare capping charges pay-as-you-go riders until they reach the price of a pass, then stops charging for the rest of the period. It depends on an account-based design. Decide whether caps run on calendar periods or rolling windows, how they interact with transfers, and whether open payment taps and agency cards cap together.

The harder work is eligibility administration. Reduced fare programs create application, verification, and renewal workload that lands on staff rather than on software. Ask how the platform supports bulk enrollment by partner organizations, employer and campus programs, re-verification, and appeals when someone is denied.

Federal requirements shape fare policy and should be checked against current Federal Transit Administration guidance and with your counsel. Conditions on federal formula funds have long required reduced off-peak fares for older adults, riders with disabilities, and Medicare cardholders on fixed route service. Department of Transportation ADA rules limit complementary paratransit fares relative to the comparable fixed route fare, and FTA guidance directs certain recipients to complete a Title VI fare equity analysis before fare changes.

Cash access for riders without bank accounts

A fare system that assumes a bank account and a smartphone will exclude riders. Plan the cash path deliberately:

Retail cash reload networks, checked against whether stores sit near high ridership stops and open when people travel.
Vending machines and a staffed sales location, including what happens when a machine is out of service.
Anonymous cards bought and loaded without an application, with a path to register one later.
Clear disclosure of any load fee, and attention to state or local cash acceptance rules.

Regional interoperability

Interoperability usually fails on governance rather than technology. Neighboring agencies can share one back office, or keep separate back offices and settle between them. Either way, write the rules down: who issues media, whose fare policy governs a shared trip, how transfers and revenue are apportioned, who pays processing fees, and how disputes are resolved. A joint powers agreement or memorandum of understanding should name the decision body.

Insist on documented interfaces rather than a promise of compatibility: published APIs for account, product, and transaction data, a certification process for new participants and new media, and fare information in the formats regional trip planners consume.

What to require when you buy

Data ownership and export. The agency owns rider accounts and transaction data, with a tested bulk export in a usable format during the term, not only at exit.
Unbundled components. Validators, back office, and payment processing should be replaceable independently. Ask what happens if you keep the hardware and change the back office.
Lifecycle and support. Who pays for payment kernel updates and scheme certifications, for how long, and what service levels and spares cover equipment on vehicles and platforms.
Privacy and retention. Trip histories are sensitive and may be subject to disclosure law. Set retention periods, access controls, and limits on secondary use before launch.
Pilot first. Run a limited route or garage with real riders and real settlement, against acceptance criteria written in advance.

HQT works with state and local agencies on systems engineering, integration, and technical oversight for programs of this kind.

Frequently asked questions

What is the difference between account-based ticketing and open payments?

Account-based ticketing describes where fare rules and balances live. In that design the media is only an identifier and the back office calculates the fare after the tap. Open payments describes what a rider may present, specifically contactless bank cards and phone wallets accepted directly at the validator. An agency can run an account-based system with only agency-issued cards, and the two choices should be evaluated separately.

Does accepting contactless bank cards put a transit agency in scope for PCI DSS?

Accepting payment card data brings the agency into the payment card industry compliance regime, though the size of that scope depends on the architecture. Point to point encryption at the validator and tokenization in the back office can keep most card data out of agency systems, which reduces but does not eliminate the validation obligation. Ask each vendor for a written responsibility matrix and current attestation covering validators, back office, and any hosted payment page, and confirm the scope with your acquiring bank and a qualified assessor.

Can fare capping work across two neighboring transit agencies?

It can, but only if the agencies agree on how a shared cap is calculated and how revenue is apportioned. That usually means either a shared back office or a settlement arrangement between back offices with agreed rules for transfers and fee allocation. The technical work is smaller than the governance work, so put the revenue and decision rules in an interagency agreement before selecting a platform.

How do riders without a bank account use an account-based fare system?

They use agency-issued media that can be bought and loaded with cash. Practical options include a retail cash reload network, vending machines, and a staffed sales location, plus anonymous cards that require no application and can be registered later. Evaluate coverage against actual ridership patterns, since a reload network only helps if participating stores are near high ridership stops and open when people travel.

Is rider trip history from a fare system a public record?

Fare system data is generally subject to your state public records law, and some categories of rider information may be exempt or restricted by state statute. Treat trip histories as sensitive, define retention periods and access controls before launch, and limit secondary use in the vendor contract. Confirm the specific disclosure and exemption rules that apply with your agency counsel, because they vary by state and change over time.