Transit fares are changing faster than most agencies can pilot a new card. Riders expect to board with whatever is already in their hands: a bank card, a phone, a printed code, or a simple account in an app. Agencies want fewer vending machines, lower cash handling, and more flexible products like daily caps instead of confusing passes. The technical name for this is account‑based ticketing (ABT). The practical goal is boarding that is as fast and trustworthy as paying at a grocery store.
This article is a field guide for teams who need to ship a modern system without a ten‑year procurement cycle. We’ll cover how to combine contactless EMV taps, barcodes, and accounts; how to build a back office you can maintain; what hardware and latency actually matter; and how to roll out safely with privacy and inclusion in mind.
What Transit Is Actually Deploying Now
Across cities, three interaction models are converging into one rider experience: tap, scan, or sign in. Under the hood, it’s all ABT—fares are calculated against an account, not stored permanently on a plastic card.
Three ways riders interact
- Tap: Riders use a contactless bank card or mobile wallet. The reader creates a tokenized “tap” that can be authorized now or later. This is often called “open‑loop” payments.
- Scan: Riders display a QR or Aztec code from an app or printed ticket. The reader validates the code against an account or a signed time‑limited payload.
- Sign In: Riders log in to an agency app with a card on file. The trip is recorded through the phone’s proximity, tapping a virtual card, or presenting a barcode.
The account-based back office is the constant. It decides products, capping, concessions, and settlement, no matter how a rider presents themselves.
Fare Media Options, Explained in Plain Language
You do not have to pick just one. Most agencies blend media so people can board in more than one way. Here’s what each option offers.
Contactless bank cards and wallets (open‑loop)
Open‑loop lets riders use the cards they already carry—Visa, Mastercard, Amex, Discover—or pay with a phone or watch. Readers run EMV contactless kernels to create secure, dynamic transactions. Back offices choose when to authorize a tap: immediately (online) or after a series of trips (deferred). With mobile wallets, devices can use Express Transit modes that work even with a dead battery on supported hardware.
Why agencies choose it: Instant onboarding, no new card to issue, fewer vending machines, and happier occasional riders. What to watch: Merchant fees, deferred authorization risk, and ensuring speed—your tap must be under a few hundred milliseconds at the gate.
Closed‑loop transit cards
These are agency‑issued cards that hold an identifier linked to an account. They can be reloadable at retail and work for unbanked riders. They are still common when cash top-up and concessions are critical, and where merchant fees for open‑loop would be too high.
Why agencies choose it: Inclusion, control over products, and predictable costs. What to watch: Card lifecycle, hot‑listing lost cards, and the ongoing expense of retail and vending networks.
QR or Aztec codes
Scannable codes represent a time‑bound right to ride. They refresh often and can be printed or shown on a screen. Modern validators read them in a second or less and can work offline by verifying signatures.
Why agencies choose it: Works on any smartphone and with paper. What to watch: Lighting, scan distance, anti‑screenshot measures, and ensuring validators reject expired codes quickly but gracefully.
So, which should you choose?
Today’s pragmatic answer: support at least two. Offer open‑loop for speed and convenience. Keep a closed‑loop or QR option for concessions, youth, visitors, and anyone without a compatible card. All of it rolls up to the same account system and fare rules.
The Back Office You Actually Need
The back office is where ABT becomes real. Think in small, testable services, not one giant monolith. At minimum, you’ll need:
- Identity and accounts: Pseudonymous by default; add verified attributes for discounts only when needed.
- Fare engine: Applies capping, products, zones, and rules to trips and taps.
- Token vault: Stores EMV tokens, device identifiers, and hotlist entries securely.
- Transaction manager: Orchestrates online, offline, and deferred authorizations and handles reversals.
- Inspection tools: Let staff verify rights to ride both online and offline, with clear operator UX.
- Reporting and settlement: For reconciliation, audits, and clearing across partners.
Fare capping that riders understand
Daily and weekly caps replace guesswork: ride until you hit the cap, then trips are free for the period. Implement tap aggregation windows (for example, midnight‑to‑midnight) and define cap hierarchies (daily beats single trip, weekly beats daily). Be explicit in receipts and in‑app messages so riders see the benefit immediately.
Deferred authorization without heartburn
To keep gates moving, you’ll batch taps and authorize later. Use risk parameters such as:
- Per‑card exposure limits and velocity checks
- Device and token risk (new, known, high‑risk BIN ranges)
- Hotlists synced to validators on a frequent schedule
Design denial experiences with dignity: a friendly light pattern, a clear display, and an alternate path (e.g., scan a QR) if a tap is rejected.
Readers, Gates, and the Latency Budget
Everything depends on speed and reliability at the edge. Riders will never see your beautiful fare engine if the reader hesitates. Aim for a sub‑300 ms tap‑to‑beep on gates and buses. Here’s how to get there:
What matters most on hardware
- EMV kernels and certification: Use proven kernels and certified hardware to avoid random declines and jittery timing.
- Local decisioning: Keep hotlists, white‑lists, and basic rules on the device so it can make instant decisions offline.
- Reliable comms: Readers should queue taps if the network drops, then sync. Don’t block passengers because the back office is taking a nap.
- Displays and UX: Clear prompts and color‑coded lights reduce confusion for first‑time users.
Design for scanning
Barcode readers must handle sunlight on buses, glossy screens, and crinkled paper. Use optics tuned for near‑field scans (50–150 mm), and refresh app codes every few seconds with a visual timer to discourage screenshots. Provide tactile targets on validators so riders know where to aim.
Accessibility and inclusion
Do not make a bank card the only way to board. Provide cash top‑up at retailers, easy concessions for students and seniors, and physical cards on request. In your app, offer voiceover‑friendly UI, color‑blind safe palettes, and large targets. On validators, include audio cues for success and failure and keep screen text legible from a meter away.
Privacy by Default
Modern fare systems can be private‑by‑design while still preventing fraud. A few practical rules:
- Tokenize PANs from bank cards and store tokens, not card numbers. Mobile wallets already provide device PANs (DPANs).
- Retention limits: Keep raw tap data only as long as required for disputes and audits. Aggregate the rest.
- Purpose limitation: Don’t repurpose location data for marketing. Communicate clearly how data is used for fares, safety, and audits.
- Anonymous accounts: Allow pseudonymous travel by default; collect identity only for discounted products with explicit consent.
Costs, Risks, and the KPIs That Matter
The business case is not just lower cash handling. Measure what actually drives rider satisfaction and financial stability.
- Tap success rate: Accept/decline ratio per validator and per medium. Aim for 99.9% reads with fewer than 1 in 500 false rejects.
- Latency: Median and 95th percentile tap time. Track separately for tap and scan.
- Cap utilization: Percentage of riders benefiting from caps—an indicator that the system is doing the math for them.
- Revenue assurance: Deferred authorization loss rate vs. interchange fees saved by batching.
- Cash displacement: Changes in cash reloads and TVM maintenance cost.
Merchant fees are real, but so are the tangible savings from fewer vending machines, lower fraud on paper passes, and reduced customer support. Run a scenario model that includes a small uptick in ridership from reduced friction; even a 1–2% increase can tip the balance in favor of open‑loop.
A Practical Rollout Plan for a Mid‑Size City
You can pilot in months, not years, if you stage the work and avoid boiling the ocean.
Phase 1: Prepare the edge
- Deploy a handful of validators that support EMV and barcode scanning on two high‑ridership lines.
- Connect readers to a sandbox back office with test fares, hotlists, and offline decisioning enabled.
- Instrument everything: log tap times, error codes, and network uptime.
Phase 2: Launch open‑loop with daily capping
- Start with adult fares only; defer concessions to a later phase.
- Enable Express Transit on supported wallets to remove friction.
- Run a controlled deferred authorization policy with low per‑card exposure until you have data.
Phase 3: Add QR and closed‑loop where needed
- Offer QR tickets in the agency app and printable vouchers for visitor centers.
- Introduce a simple closed‑loop card with retail top‑up for unbanked riders and youth programs.
- Bring in concessions via verified attributes (student, senior) tied to accounts, not card type.
Phase 4: Expand, iterate, and settle with partners
- Extend to regional partners and agree on revenue sharing based on trip data, not fare media.
- Refine risk settings. Increase deferred limits where loss rates are low; tune hotlists where they’re not.
- Publish fare products through open APIs so trip planners and MaaS apps can show caps and costs before a journey.
Integration With Trip Planners and MaaS
Customers do not think in “products.” They ask: “What will this trip cost me?” Connect fares to planning tools so the answer is immediate and accurate.
Data you should publish
- GTFS schedules and GTFS‑Realtime: The baseline for most planners.
- GTFS‑Fares v2: Publish zones, caps, and rules so apps can price trips correctly.
- Entitlements API: A simple endpoint where app partners can verify a rider’s products (e.g., “has weekly cap,” “student concession”) with consent.
- Ticketing API: For creating QR tickets and linking them to accounts with standardized fields and time windows.
Keep APIs well‑documented and versioned. Your developer portal is part of your rider experience.
Barcodes Done Right
Barcodes are not a second‑class citizen. With solid design, they can be fast and secure.
Security and UX practices
- Short lifetimes: Rotate on screen every 5–15 seconds, with server‑side expiry even for snapshots.
- Signed payloads: Use asymmetric cryptography so validators can verify offline. Encrypt only if you need secrecy; signatures are usually enough.
- Visual timers and animations: Indicate freshness and help staff spot static screenshots.
- Paper‑friendly: Provide a high‑contrast print option with generous error correction for older printers.
Train staff how to recognize genuine codes and fallbacks. If a phone screen is broken or too dim, point riders to QR kiosks or instant paper issuance at key stations.
Fraud, Risk, and Inspection Without Friction
Good systems assume some loss and design for low‑friction deterrence rather than confrontation.
- Risk analytics: Look for patterns (repeated declines, tap velocity, devices with abnormal error rates) and adjust limits dynamically.
- Randomized inspection: Equip inspectors with fast offline readers. Use respectful scripts and offer in‑place payment options where legal.
- Transparent appeals: If a legitimate rider is denied due to risk scoring, make it easy to resolve and learn from the case.
Cross‑Agency Travel Without the Headache
The dream is simple: board across operators with the same card or account, and the back offices settle later. You don’t need a grand unification to get started.
- Token federation: Allow a partner to accept your tokens (card, QR, or device) and send trip records for settlement.
- Shared fare models: Agree on caps that work across zones and operators. Keep edge validators simple and push complexity to the back office.
- Clearing rules: Settle weekly based on validated trips, not assumptions, and include service quality adjustments if needed.
If you publish your rules and endpoints, regional partners can connect at their own pace, and riders will feel the system “just works.”
Testing: Prove It on the Platform
Lab tests are necessary; platform tests are decisive. Create a checklist and don’t ship without numbers.
What to verify before citywide launch
- Validator cold start time and behavior when the network is down
- Median and P95 tap latency for each medium (open‑loop, closed‑loop, QR)
- Decline reason distribution and operator UX for handling each case
- Hotlist sync frequency and validation against injected test tokens
- Data retention and delete‑on‑request workflows, verified with real accounts
Communication and Support
Technology succeeds when customers understand it. Plan for communication as a first‑class deliverable.
- Plain‑language guides on caps and accepted media with diagrams and short clips.
- Signage at validators: tap angle, scan target, and what the lights mean.
- Receipts and history: Easy access in app and email with clear fare logic shown.
- Fallbacks: Scripted help at stations for declines, broken screens, or misplaced cards.
Build trust by showing the math: if a rider hit a daily cap, say so right on the validator and in the receipt.
Common Pitfalls (and How to Avoid Them)
- Monolithic procurements: Break projects into edge, back office, and apps with clear contracts. Swap parts without starting over.
- Over‑customized products: Start with simple caps and a small product set. Complexity confuses riders and breaks integrations.
- Ignoring offline: Validators must keep boarding when the network drops. Simulate outages in testing.
- Privacy as an afterthought: Decide retention and deletion policies before launch. Communicate them plainly.
What’s Next: Simple, Interoperable, and Boring
The best transit payment is uneventful. Over the next few years, expect more agencies to converge on simple fare rules, open APIs, and hardware that fades into the background. QR will remain a workhorse for inclusivity and events. Open‑loop will keep growing for its convenience. Closed‑loop will serve concessions and communities that need cash reloads. The back office—modular, auditable, and privacy‑safe—ties it together.
Don’t chase novelty. Ship the boring parts well, and your riders will notice only the one metric that matters: they got where they needed to go, without thinking about the ticket.
Summary:
- Adopt account‑based ticketing so tap, scan, and sign‑in all work with one fare engine.
- Blend open‑loop with QR or closed‑loop to serve both convenience and inclusion.
- Engineer validators for sub‑300 ms taps, clear UX, and offline decisioning.
- Build a modular back office: accounts, fare engine, token vault, transaction manager, inspection, and settlement.
- Implement daily/weekly caps and explain them clearly in receipts and on‑device messages.
- Manage deferred authorization with risk limits, hotlists, and kind denial experiences.
- Publish GTFS‑Fares v2 and simple APIs so trip apps can show accurate costs.
- Use privacy by default: tokenization, limited retention, and pseudonymous accounts.
- Roll out in phases, measure tap success and latency, and tune based on real riders.
- Coordinate regionally with token federation and trip‑based settlement, not media‑based rules.
