Collecting fares on public transit. 6 chapters and a final quiz.

Chapter 1. Pricing the trade-off before choosing an architecture.

An operator is not choosing between two technologies but between two cost structures. A closed loop ties up capital in a fleet of fare media and collects before the ride; an open loop ties up nothing and collects after the trip, once the period has closed. One metric decides between them: the all-in cost per tap. Everything else follows from it.

You will not find this cost in any sales brochure: it is built line by line from the operator's own statements. Two items dominate it: the fixed component of the processing fee, charged on every transaction, and the annualized cost of the fare media fleet. The first penalizes small amounts, the second large fleets.

PARAMETERS TO FILL IN FROM YOUR OWN STATEMENTS
  t   average fare collected per tap              (monetary unit u)
  n   taps per rider per period                   (aggregation period)
  cv  percentage component of the processing fee (%)
  cf  fixed component of the fee                  (u per transaction)
  S   annualized cost of the fare media fleet / annual taps
  F   float income / annual taps
  I   net unpaid fares observed / taps

COST PER TAP, OPEN LOOP
  cost = t*cv + cf/n + I
                  ^^^^ the fixed component is DIVIDED by the number
                       of taps aggregated into a single debit

COST PER TAP, CLOSED LOOP
  cost = (acceptance cost of the reload / n_reload) + S - F

WORKED EXAMPLE — ILLUSTRATIVE VALUES, NOT MARKET DATA
  t = 2.00 u   cv = 1.2%   cf = 0.05 u   I = 0.01 u

  n = 1  (one debit per tap)           -> 0.024 + 0.050 + 0.01 = 0.084 u
  n = 4  (daily aggregation)           -> 0.024 + 0.0125 + 0.01 = 0.047 u
  n = 20 (weekly aggregation)          -> 0.024 + 0.0025 + 0.01 = 0.037 u

READING
  From n=1 to n=4, the cost drops 44%. From n=4 to n=20, only 21%.
  The return on aggregation runs out fast; exposure, by contrast, grows
  linearly with the length of the period. The stopping point is calculated,
  not decreed.

Chapter 2. Holding the decision budget at the entry point.

The entry point must show a green or red light in under a second, and the U.S. Payments Forum sets the target at no more than 500 milliseconds after a valid tap, including presentation of the card or device. A second requirement follows, less often cited and far more demanding: the reader must not need to contact the operator's server to decide. Everything that controls whether the gate opens lives in the reader.

• Certification authority public keys (CAPKs) for each accepted network, current and correctly loaded.
• The list of accepted application identifiers (AIDs), and the selection logic when the card offers several.
• The operator's deny list, replicated locally and checked on every tap.
• Fare parameters needed for display, never for calculating the final price.
• A local tap queue, sized for the longest offline period the operator accepts.

The three levels of offline authentication

Chapter 3. Wiring the rail: three pillars and a deferred authorization.

An ordinary card transaction rests on three pillars: authenticate the card, verify the cardholder, obtain authorization. Transit keeps all three but resolves them differently, because none of them fits in the time available at the entry point. The U.S. Payments Forum formalized this triad in 2018, and it still shapes configurations today.

Deferred authorization has a strict definition, and a broader one than it looks: any request sent after the rider has been allowed to travel falls under it. The delay does not matter. A request sent three seconds after the gate opened is handled exactly like one sent the next day, and the indicator that flags this status is agreed network by network.

TRAP 1 — THE TRANSACTION COUNTER ARRIVES OUT OF ORDER

  Every chip increments a counter (ATC) with each transaction.
  Many issuers check that it keeps moving forward to detect a cloned card.

  In transit, authorizations go out AFTER the fact, sometimes
  from entry points that were offline at different times.

    tap 09:12  ATC=0141  offline entry point  -> authorization sent at 11:40
    tap 09:47  ATC=0142  online entry point   -> authorization sent at 09:47

  The issuer receives 0142, THEN 0141. A strict check reads this as an anomaly.
  ACTION: out-of-order counters are normal in transit. The operator
  documents this with the networks; issuers widen their
  tolerance instead of declining.

TRAP 2 — THE CRYPTOGRAM AMOUNT IS NOT THE REQUESTED AMOUNT

  At the moment of the tap, the fare is UNKNOWN. Yet the chip generates its
  cryptogram over an amount (tag 9F02, carried in
  field 55). The amount actually requested from the issuer is
  calculated after the fact and sits in a different field of the message.

    9F02 (in field 55) ....... amount seen by the chip at the tap
    requested amount ......... aggregated total for the period

  These two values DIFFER, and that is the expected behavior.
  ACTION: validate the cryptogram on the field 55 data alone.
  Any cross-check against the requested amount makes
  verification fail and produces a decline that should never have happened.

Revenue is classified according to the merchant category code (MCC) the acquirer sends. That code is not a mere declaration. It determines which interchange schedule applies, eligibility for the networks' transit rules, and how disputes are handled. A wrong code costs money on every transaction, for years, without ever triggering an alert, so the code must be checked on the first batches, transaction by transaction.

Chapter 4. Capping fares: a pivot identifier and a replayable calculation.

Capping requires recognizing that several taps belong to the same account; otherwise there is no cap, just a running total. The problem arrived with mobile wallets: a phone does not present the card number but a device-specific number, and a watch presents a third one. Three devices, three identifiers, three caps calculated separately.

The identifier that links all the devices on one account

EMVCo defined the Payment Account Reference, or PAR, for exactly this: a 29-character identifier tied to a payment account, not to a cardholder. It accompanies the actual card number as well as each device number derived from it, so two devices sharing the same PAR point to the same account. That gives the operator its capping pivot.

INPUTS
  taps(pivot, window)       pivot = PAR if available, otherwise the device identifier
  fares(trip)               unit price rebuilt from tap-in/tap-out
  caps(zone, window)        daily, weekly, by mode

SERVICE DAY
  It does not start at midnight. It is defined, published, and enforceable
  against a rider who disputes a cap. If it is not published, there is no defense.

CALCULATION
  1. rebuild the trips            match tap-ins with tap-outs
  2. price each trip              missing tap-out -> explicit rule
  3. total over the window        day, then week
  4. apply the most favorable cap
  5. deduct what has ALREADY been authorized over the window
  6. charge the difference        never the recalculated total

REPLAYABILITY — the property everything else depends on
  A tap uploaded late from an offline entry point
  ARRIVES AFTER its window has closed. The calculation must then:
    · replay over the window concerned,
    · compare with the amount already authorized,
    · charge only a top-up, or issue a refund.
  A calculation that cannot be replayed double-charges on every network incident.

CASES TO COVER WITH A TEST, ONE BY ONE
  · two devices on the same account, with PAR / without PAR
  · missed tap-out, then a rider complaint
  · double tap at the same entry point within a few seconds
  · tap arriving after its window has closed
  · trip spanning two service days
  · cap already reached, then a trip canceled

Chapter 5. Containing unpaid fares: first ride, deny list, debt recovery.

The industry calls it first-tap risk. An unfunded account gets through the entry point once without any obstacle, since nobody was asked, and the ride taken cannot be recovered. The whole setup therefore targets the second tap, never the first. The goal is to bound this risk at a known cost, not to eliminate it.

EXPOSURE FROM A BAD CARD

  E = average_fare x taps_before_block

  taps_before_block
      = taps during the current aggregation period
      + taps during the listing delay
      + taps during propagation to the readers

  Three delays, three different owners:
    aggregation period ...... operator's decision (chapter 1)
    listing delay ........... processing of authorization responses
    propagation delay ....... reader fleet infrastructure

METRICS TO PRODUCE FROM LAUNCH, NOT LATER
  · decline rate after period close, by issuer reason
  · median and maximum deny list propagation time
  · unsettled balance to date, by age
  · 30-day recovery rate
  · missing tap-out rate BY STATION and BY ENTRY POINT

A network-wide average missing tap-out rate means nothing.
A single badly placed entry point generates maximum fares
charged in error, and the disputes that come with them.

Chapter 6. Contracting with the acquirer, then testing.

An open-loop ticketing program rarely fails at reading the chip. It fails on what the acquirer cannot do, and what nobody thought to require in writing before signing. Transit departs from standard acquiring on a series of specific points, and each one becomes a contract clause, then a test case.

• Handle an amount that is unknown at the time of the tap under the network's transit rules, without format rejects.
• Accept deferred authorizations sent after the trip, with the indicator agreed network by network.
• Absorb the volume: a dense network generates authorization peaks unlike anything in retail.
• Pass through the actual decline reason without converting it into a generic decline.
• Return the PAR in the authorization response, for tokenized and non-tokenized accounts alike.
• Manage the life cycle of certification authority keys: loading, renewal, and removal across the entire fleet.
• Issue reversals and re-presentments on transit transactions, to correct a cap or a missing tap-out.
• Apply the agreed merchant category code, verifiable on batches from the first week.