🚇 Payments in transit

Two architectures: the card that holds the value, the account that calculates it

Fare collection covers the cards, devices, equipment, and systems used to sell a ticket, check it, and collect its price. Transit operators built these systems before the payments industry took any interest in the market. The constraint came from where payment took place. A fare gate handles a continuous stream of riders, and an ordinary card transaction is too slow for that pace. So operators issued their own money, on their own media, with their own contactless technology. Octopus led the way in Hong Kong in 1997, followed by Suica in Japan in 2001, EasyCard in Taiwan in 2002, and T-money in South Korea in 2004.

Two architectures coexist. In the card-centric model, the stored value is written to the chip on the card, and the gate debits the card offline without contacting any remote system. In account-based ticketing (ABT), the card carries only an identifier, and the fare is calculated in the back office after the trip. What separates the two is where the fare is determined. That choice then dictates which fare structures are feasible, how risk is shared, and which media can be accepted.

The shift to account-based systems was driven more by changing costs than by a new idea. It became workable once connectivity and storage costs collapsed. A gate now uploads its taps continuously, and a back office recalculates fares for tens of millions of trips every night. Contactless payment cards arrived in this setting, where they serve as a means of identification rather than as a ticket.

The gate constraint: a few hundred milliseconds

A fare gate is a barrier that grants or denies access to the network after reading a card or device. It is sized in passages per minute, and its cycle time sets the capacity of the station. The industry’s accepted time budget is under 500 milliseconds, including the time to present the card, and deployed technologies aim well below that. Sony quotes about 0.1 second per transaction for FeliCa, the technology behind Suica and PASMO. Bank Indonesia cites about 0.3 second for QRIS Tap, the contactless extension of Indonesia’s QR standard launched in 2025.

That time budget rules out online authorization. A card authorization request already takes 100 to 300 milliseconds of decision time at the issuer, before any network transit time, and the full round trip takes one to two seconds. That is two to four times the gate’s entire budget. At a busy transfer station during rush hour, the gap slows each passage so much that the line stops clearing as fast as riders arrive.

• Powering the card and handling anticollision at 13.56 MHz, under ISO/IEC 14443 for EMV and MIFARE and JIS X 6319-4 for FeliCa.
• Selecting the application and running the cryptographic exchange with the chip.
• Reading the payment identifier, then hashing it into an account identifier in account-based systems.
• Checking a deny list (hotlist) stored locally in the gate.
• Deciding to open, and writing the tap to a queue that is later uploaded to the back office.

Degraded mode is part of the system design, not of incident handling. A gate that loses contact with its back office must keep opening. It then relies on a deny list that may be minutes or hours old, and it stores its taps in a local queue until the link comes back. The operator sets how long this state is tolerated, and that duration directly determines the financial exposure it accepts.

London: the open loop and what it actually eliminated

Oyster is Transport for London’s proprietary contactless card, launched on June 30, 2003, on a MIFARE chip and an architecture supplied by Cubic Transportation Systems. By mid-2012, more than 43 million cards had been issued, and more than 80% of trips on London public transit were paid with Oyster (TfL, 2012). Oyster is still a card that has to be manufactured, distributed, topped up, and managed. Opening the network to payment cards, starting with buses in December 2012, targeted those four cost lines.

The savings expected from open loop show up in the operating budget, line by line. The operator no longer manufactures cards or maintains ticket machines in every station. It no longer holds prepaid funds that must be safeguarded and later refunded. It no longer pays a network of top-up outlets. Occasional riders, and visitors in particular, no longer buy anything before entering the system.

• The rider no longer chooses a ticket: they tap, and the system applies the best fare they were entitled to after the fact.
• The operator loses upfront revenue: no more stored balances, no more tickets bought and never used.
• The card issuer joins the chain: it holds the account and handles tokenization and disputes.
• The back office becomes the revenue system: its availability now affects billing, no longer whether the gates open.

Capped fares, calculated after the trip

Fare capping automatically limits the amount a rider is charged over a given period, once all their taps are known. It follows directly from account-based ticketing, because the back office is the only part of the system that sees every trip in the period. Transport for London applies it across zones 1 to 9, where pay-as-you-go fares are capped. A rider can travel as much as they like over a day, or over a Monday-to-Sunday week, without paying more. No pass is bought in advance, and the system applies the best fare the rider was entitled to after the fact.

This calculation depends on one technical condition. The system must link several taps to the same rider, and the identifier derived from the payment card or device is the key to that link. Transport for London turns this into an explicit instruction for riders: tap in and out with the same card or device, because using a phone and then a watch on the same trip leads to a higher charge.

Capping shifts the job of finding the cheapest fare from the rider to the operator. Riders no longer buy a pass just in case, or pay full fare because they do not understand the fare table. Revenue automatically falls from riders who used to overspend, while it rises from riders who were put off by complex fares. The relative size of these two effects depends on the rider mix, so each network has to make the call using its own ridership data.

• A stable account identifier over time, one that survives card reissuance and device changes.
• A fixed calculation window: the operating day rarely starts at midnight, and the offset must be enforceable against riders.
• The ability to rerun the calculation when a tap arrives late from a gate that was offline.
• A correction policy: cap charged twice, missing exit, duplicate tap at the same gate.
• A trip history the cardholder can view, trip by trip; without it, no dispute can be defended.

Deferred debit: the ride is taken before it is paid for

Deferred debit means charging for trips after they are taken, when an aggregation period closes. In an open loop, the operator provides the service before knowing whether the card presented is good. The gate does not contact the issuer. It opens based on a local list, and the authorization request comes only after the period closes. In between, the operator is owed money by a cardholder whose identity it does not know. All it has is a truncated card number and a timestamp.

Operators have a name for this risk: first-ride risk. A card that is stolen, expired, out of funds, or simply unknown gets through the gate the first time without any trouble, because there is no online check at the gate. Risk controls therefore aim to block the second ride and to limit what the first one costs.

• Status check on first use: a zero-amount or minimal authorization request, sent as soon as the first tap is known, confirms that the card exists and is not blocked.
• Deny list stored in the gate: updates are pushed to every gate; the propagation delay measures the real exposure.
• Exposure limit per card: above a set unpaid balance, entry is refused until the debt is cleared.
• Faster close: the shorter the aggregation period, the smaller the potential loss, and the higher the acceptance cost per tap.
• Collection and blocking: an unpaid charge puts the identifier on the deny list, and the cardholder must pay before traveling again.

ACCOUNT IDENTIFIER: hash(PAN|expiry) -> a9f3...c210
OPERATING DAY: 04:30 D -> 04:29 D+1

  07:12  ENTRY    station A     offline tap, deny list OK
  07:41  EXIT     station B     trip 1 rebuilt -> full fare
  12:55  ENTRY    station B     offline tap
  13:10  EXIT     station C     trip 2 rebuilt -> full fare
  18:30  ENTRY    station C     gate offline: tap queued
  19:02  EXIT     station A     trip 3 -> uploaded at 19:40, not real time

END-OF-DAY CALCULATION (D+1, after close)
  sum of trips ..................... 3 trips at standard fare
  daily cap applied ................ yes -> amount reduced to cap
  AMOUNT TO AUTHORIZE .............. daily cap for the zone traveled

  -> 1 authorization, 1 clearing presentment, 1 statement line
  -> more than 21 hours between the first tap and the call to the issuer

This revenue is classified under the merchant category code (MCC) system (ISO 18245). Local and suburban passenger transit, including ferries, falls under 4111; passenger rail under 4112; and bus lines under 4131. Taxis and limousines use 4121, and tolls 4784. The code has direct contractual consequences. It determines the applicable interchange rates, eligibility for cardholder verification waivers, and how disputes are handled.

How the London model spread

The London model spread through technology transfer rather than imitation. The same system is taken to another operator by the vendor that built it, under license from the agency that commissioned it. Cubic Transportation Systems, the prime contractor for Oyster, built OMNY in New York using technology licensed from Transport for London. Cubic also runs the Opal system in Sydney. Three of the world’s busiest transit networks therefore share the same technical lineage. In practice, only a handful of integrators can deliver an open-loop fare system.

Three conditions determine whether a network can open up. First, the share of riders carrying locally accepted contactless cards must be high; otherwise the operator ends up running two systems instead of one. Second, the average fare must be able to absorb an acceptance fee, even on an aggregated amount. Third, fares must be calculable after the fact, which rules out fare tables that require riders to declare their trip in advance. A network whose fare depends on a zone declared at purchase therefore cannot switch without redesigning its fare table.

East Asia’s closed loops, beyond transit

A closed loop is a payment system in which the issuer, the card, and the acceptance network all belong to one operator, with no international card network involved. East Asia used these systems to follow the opposite path from London. Instead of bringing payment cards into transit, it took the transit card beyond transit. Octopus, Suica, EasyCard, and T-money became everyday e-money, accepted at convenience stores, vending machines, cafeterias, and parking garages. The daily commute gives them a frequency of use that no bank instrument achieves in those markets.

Interoperability here rests on an agreement between operators, not on a payment card standard. Since 2013, the network of 10 interoperable transit IC cards has linked JR East, JR West, JR Central, JR Kyushu, JR Hokkaido, and the private operators that issue the group’s other cards. The 10 cards are Suica, PASMO, ICOCA, TOICA, SUGOCA, Kitaca, manaca, PiTaPa, nimoca, and はやかけん. A card bought in Fukuoka works in Sapporo, and the whole system runs on FeliCa, with no QR codes at all. PiTaPa, in the Kansai region, is the only exception in the group. It is postpaid, with partial interoperability outside transit.

The card then went digital without any change in architecture. Smart Octopus came to Samsung Pay in 2017, to Apple Pay and Huawei Pay in 2020, and to Google Wallet in 2024. JR East reports 33 million Mobile Suica accounts and in March 2025 launched Welcome Suica Mobile for iPhone, aimed at visitors and valid for 180 days. In Taiwan, EasyCard’s issuer now runs 悠遊付 (EasyWallet), a licensed wallet that lets riders pay by phone on the Taipei and New Taipei MRT, on buses, and for YouBike.

A hardware constraint keeps these markets apart from the rest of the world for the long term. A contactless EMV terminal imported from Europe or North America cannot read Suica, Octopus, or the postpaid FeliCa schemes iD and QUICPay. Acceptance requires a FeliCa-certified reader. Replacing readers is therefore the biggest hardware cost of opening up in Japan, and it has to be assessed before committing to a rollout.

Operating models compared: who owns the account, who holds the money

An operating model here means how issuing the card, holding the funds, and paying for each tap are split between the transit operator and the payments industry. Four models share the world of transit payments, and card technology is not the main thing that sets them apart. Three factors separate them: who owns the relationship with the rider, where the money sits before the trip, and who pays the unit cost of each tap.

Open loop replaces the float with a cost structure that ties up no capital. The operator does not produce or distribute cards, and it refunds no balances. It pays a fee on an aggregated amount, and its deny list limits the bad-debt risk it carries. Which model comes out ahead depends mostly on the average fare and on the share of occasional riders. A low-fare network used mostly by pass holders has a lot to lose by opening up, while a high-fare network used by tourists has a lot to gain.

• The aggregation period trades acceptance cost against exposure: the longer it is, the less the fixed fee weighs, and the larger the potential bad debt.
• The merchant category code determines the interchange rates; a wrong code costs money on every transaction, for years.
• The share of foreign cards determines the true cost: a tourist network pays interregional rates that bear no relation to domestic ones.
• The missing-exit rate drives both maximum-fare charges and disputes; it must be measured station by station, not as a network average.
• The deny list propagation delay directly measures the fraud the operator accepts, and it is the only figure the operator fully controls.

What an operator must lock down before opening up

A revenue system is the set of rules and processes an operator uses to set, bill, and collect fares. Opening a network to payment cards is a revenue system project, and payment acceptance is only one part of it. When these programs fail, the cause is rarely the hardware. It is usually fares, the ability to prove a trip took place, or customer service.

• Make the fare table calculable after the fact. Any rule that requires the trip to be declared in advance must be dropped or recast as a capping rule.
• Define the operating day and publish it. A day that starts at 4:30 a.m. must be enforceable against a cardholder who disputes a cap.
• Set a target propagation delay for the deny list, and measure it in production. It is the only metric that limits fraud.
• Choose the aggregation period with a clear view of the trade-off between acceptance cost and exposure, and revise it based on real data.
• Write the merchant category code into the acquirer contract, and check that it is applied to every transaction from the very first batches.
• Publish a searchable trip history by card identifier, with no account required; without it, no dispute can be defended.
• Track the missing-exit rate by station and by gate, before the commercial launch, not after.
• Keep a non-bank payment option for reduced fares, minors, and riders without a card, until a truly universal alternative exists.

The geographic divide remains sharp in 2026. East Asia has kept its closed loops and extended them into retail. Europe and North America have opened their gates to payment cards. South Asia and Southeast Asia are choosing between cards built on a national scheme and faster QR payments. None of these choices can be reversed cheaply. Replacing a validation medium means swapping out the entire hardware base, while changing the fare architecture means rebuilding fare calculation, billing, and dispute handling.