# Open-loop tap-to-pay: what happens between the tap and the charge

> The gate opens before anyone has checked whether the card works. Here is the back office behind contactless transit fares: deny lists, aggregation, deferred authorization, and why most 2026 launches shipped at adult full fare only.

Published 2026-08-14 by Nick Sawinyh.
Report in Agency IT.
Canonical: https://its-feed.com/articles/open-loop-tap-to-pay/
Keywords: account based fare collection, account based ticketing system, open loop account based ticketing, automatic fare collection system, contactless transit payment

---

A rider taps a bank card at a fare gate and walks through. The gate has not
checked whether the card has money on it. It has not asked the bank anything at
all. Nobody has calculated a fare, and depending on what the rider does for the
rest of the day, the eventual charge might cover this trip and four others, or
might never arrive.

Everything interesting about contactless transit fares happens in that gap. The
tap is the part riders see and the part agencies put on posters. The part that
determines what a rider can actually do, whether they can get a discount, whether
a weekly cap works, whether a transfer is free, sits in a back office that no
press release describes.

This matters right now because 2026 was the year open-loop stopped being a
large-agency experiment. [Puget
Sound](https://www.soundtransit.org/get-to-know-us/news-events/news-releases/tap-to-pay-puget-sound-region-transit-systems-to-accept)
switched on six agencies at once in February. [LA
Metro](https://ktla.com/news/local-news/la-metro-contactless-fare-payments-new-app-world-cup/)
launched in May. [KCATA](https://ridekc.org/kcata/news/kcata-and-ridekc-to-resumes-bus-fares-june-1/)
ended more than five years of fare-free service, removed cash from its buses, and
stood up open-loop payments on the same day, three weeks before Kansas City hosted
World Cup matches. Every one of them was announced as open-loop, and the systems
underneath differ enough that riders got materially different things.

## Nobody checks the card before the gate opens

Start with what the reader does in the fraction of a second the gate is open.

The card and the reader run offline data authentication, which the card networks
describe plainly as necessary "so that cardholders can quickly tap and enter the
transit system." The reader then computes a card hash, [defined
as](https://developer.cybersource.com/docs/cybs/en-us/urban-mobility/developer/ctv/rest/mass-transit/um-intro-overview/um-intro-terms.html)
a "one-way hash token ID of the payment card data that is used to maintain the deny
list," and compares it against a list of hashes held locally on the terminal. If
the hash is on the list, [the card "is not approved for travel and the terminal
does not open the
gate."](https://developer.cybersource.com/docs/cybs/en-us/urban-mobility/developer/ctv/rest/mass-transit/um-transit-models-flows-intro/um-models-flows-common-intro.html)
If it is absent, the gate opens.

Nothing in that sequence reaches the issuing bank. The reader requests no
authorization and checks no balance. The decision to admit the rider rests entirely
on a list of known-bad cards that was compiled somewhere else and pushed to the
reader some time ago. On Mastercard's Pay As You Go model
[that list is "automatically updated every 20
minutes"](https://developer.cybersource.com/docs/cybs/en-us/urban-mobility/developer/ctv/rest/mass-transit/um-transit-models-flows-intro/um-models-flows-mc-payg-intro.html),
which is fast for a distributed system and an eternity for a card that was
cancelled at 9:02.

The agency is taking a bet on every tap. It has to, because the alternative is a
gate that waits for a network round trip, and a gate that waits is a gate with a
queue behind it.

![Flow diagram of an open-loop transit transaction in two phases. At the gate, in under a second: the card and reader perform offline data authentication, the reader computes a card hash, checks it against the locally stored deny list, and opens the gate. No bank contact occurs. Over the travel period, typically 24 hours: taps accumulate, the back office performs journey reconstruction and prices the accumulated trips, then submits a single deferred authorization, a combined authorization and capture. If approved, the rider is charged once for all trips. If declined, the card hash is added to the deny list and pushed back to every reader, and above the chargeback threshold the balance moves to debt recovery.](https://its-feed.com/charts/open-loop-tap-to-pay-transaction-flow.png)

*The gate opens on a local list lookup. Everything that resembles a payment happens hours later, once, for every tap at the same time. Source: Transaction sequence as documented in the Cybersource and Visa Acceptance mass transit processing guides, read 2026-08-14.*

## The charge comes later, and it covers everything at once

Taps accumulate over what the specifications call a travel period: the window
"during which a traveler can make multiple taps in and out of the transit system,
before you submit the final payment transaction for the aggregated amount." It is
usually 24 hours.

During that window the back office is doing the work the gate could not. It records
every tap, then performs what the documentation calls journey reconstruction,
assembling those taps into trips, because on a distance-based system the fare is
not knowable until the rider gets off. Then it applies the fare rules: the base
fare, any transfer window, any cap.

Only at the end does anything resembling a payment occur. The back office submits a
deferred authorization, defined as a "combined authorization and capture request,
also known as a sale, for aggregated fare payments." One transaction, covering
every tap in the period. This is why a rider who took four buses on Tuesday sees one line on
their statement on Wednesday, and why that line matches no individual fare on the
agency's own fare table.

It is also why the familiar complaint that "the transit charge on my card is wrong"
is usually not wrong. It is aggregated.

## What happens when the bet loses

If the deferred authorization is declined, the agency has already provided the
rides. The recovery machinery is where the model shows its edges.

The card hash goes on the deny list, which propagates back out to every reader on
the system, and the rider is refused at the next gate. If the declined amount is
above the chargeback threshold, the balance "is moved to debt recovery," a separate
process of resubmitting the authorization until it succeeds. Getting the card back
off the list requires a successful debt recovery transaction, and the documentation
is specific that this "must be completed within one hour of receiving the
authorization approval." Miss the window and the rider is still locked out despite
having paid.

The first ride has its own regime. The card networks call it [First Ride
Risk](https://developer.cybersource.com/docs/cybs/en-us/urban-mobility/developer/ctv/rest/mass-transit/um-intro-overview/um-workflow-first-ride-risk.html),
which "addresses the liability for the first use of a payment credential that fails
pre-authorization and might result in a refusal for travel." When a card fails
verification on its very first tap, the operator can attempt to capture the fare
anyway, but only where the decline came back with one of 24 specific response
codes. Outside that list, the ride was free and the agency absorbs it.

That is the deal. The agency accepts a small, continuous rate of loss in exchange
for gates that open instantly and riders who do not need to buy anything before
they travel. Usually that trade is worth making, but the loss is real, and an
agency evaluating open-loop should price it as an operating cost rather than treat
it as a defect to be engineered away. The four rural California agencies of the Far North
Transit Group [reported processing costs averaging 25 cents per transaction, just
under 7 percent of total fare
revenue](https://learn.sharedusemobilitycenter.org/casestudy/open-loop-transit-payments-summary/),
which is the clearest published figure on what the convenience costs at small
scale. Fare revenue is one of the things agencies report to [the National Transit
Database](https://its-feed.com/articles/national-transit-database/) every year, so the aggregate effect
of the switch will eventually be visible there, net of processing fees.

## Same word, different systems

The back office becomes visible to riders in what a launch does and does not
support. Four of them, side by side.

| Agency | Live | What riders get | What they do not |
|---|---|---|---|
| Puget Sound ORCA | 2026-02-23 | Adult fare, 2-hour transfer window, six agencies | Senior, youth, ORCA LIFT and disabled discounts; passes; paying for a companion |
| WMATA | Bus 2025-11-18, rail May 2025 | Bus and rail on one card | Discounts and SmartBenefits still need SmarTrip; multi-day passes SmarTrip only |
| RTD Denver | 2025-11-25 | Validators on 952 buses and at 78 stations | Amex and Discover deferred to later in 2026 |
| LA Metro TAP Plus | May 2026 | Fare capping, free Metro transfers, interagency transfers, transaction history, paying for family on one card | Further features stated as arriving through 2027 |

Three of the four shipped adult full fare and little else. LA Metro shipped
capping, transfers, and group payment. All four are open-loop. The term describes
what the rider taps, and nothing about what the agency built to receive it.

That gap is not neglect. It comes from a constraint every open-loop system runs
into, and it is the hard problem in this technology.

## A bank card identifies an account, not a person

A closed-loop transit card can carry a rider's status. The agency issued it, so the
agency can encode that this card belongs to a senior, or a student, or someone
enrolled in a low-income program.

A contactless bank card carries none of that. As the Shared-Use Mobility Center
puts it, because open-loop "allows travelers to tap their own bank card, it does not
necessarily associate the card with a specific person and eligible benefits." The
back office sees a token. It cannot see a rider.

So every discount, every pass, and every fare cap on an open-loop system requires
binding that token to an eligibility record, which means the rider has to register
the card with somebody. Two production approaches exist in the US. New York's OMNY
added bank-card discounts by having eligible riders register through the OMNY
website. California went the other way and built the verification once for
everybody: Cal-ITP's Benefits application uses Login.gov to confirm eligibility and
then attaches the benefit to the rider's own contactless card, so the same
registration works across participating agencies.

That registration step is the entire difference between the LA Metro row and the
other three in the table above. It is also why fare capping, which we covered in
[the explainer on fare payment
modernization](https://its-feed.com/articles/fare-payment-modernization/), is native to account-based
systems in principle and still absent from most open-loop launches in practice.
Capping an anonymous token is straightforward. Capping one that has to carry an
eligibility status is the part that takes years.

## The part nobody filled in

GTFS can express contactless acceptance. [The
specification](https://gtfs.org/documentation/schedule/reference/) defines
`fare_media_type = 3` as "cEMV (contactless Europay, Mastercard and Visa) as an
open-loop token container for account-based ticketing," and provides a
`cemv_support` field on both `agency.txt` and `routes.txt`, with values for
supported, not supported, and no information. An agency that takes bank cards can
say so in machine-readable form, and every trip planner reading the feed would
know.

We checked how many do. We took the [MobilityData
catalog](https://mobilitydatabase.org/) of GTFS sources, all 1,174 US entries, and
read `agency.txt`, `routes.txt`, and `fare_media.txt` out of each feed.

![Bar chart of cEMV declaration in US GTFS feeds as of August 14, 2026. Of 803 readable feeds not marked deprecated or inactive, 16 declare contactless bank card acceptance, representing 11 distinct operators, and 787 declare nothing. Below, field usage: fare_media.txt appears in 39 feeds and carries a cEMV row in 15; agency.cemv_support appears in 4 feeds, set to supported in 2; routes.cemv_support appears in 3 feeds, set to supported in 1.](https://its-feed.com/charts/open-loop-tap-to-pay-cemv-declarations.png)

*Eleven operators nationwide tell the data what a poster at the fare gate already says. Source: ITS Feed analysis of the MobilityData GTFS catalog. All 1,174 US sources were requested on 2026-08-14; 1,136 returned a readable feed, of which 803 were not marked deprecated or inactive.*

The result rhymes with what we found [surveying GBFS feeds for version
adoption](https://its-feed.com/articles/shared-mobility-data-stack/): the specification is well ahead
of what US operators actually publish.

Sixteen of 803 live feeds declare it, and those sixteen represent eleven distinct
operators: TriMet, C-TRAN, the ORCA region, SEPTA, Spokane Transit, Madison Metro,
Greater Cleveland RTA, Trinity Metro, Long Beach Transit, Santa Barbara MTD, and
Rochester's RGRTA. The individual fields are thinner still. Across the entire
country, `agency.cemv_support` appears in four feeds and is set to "supported" in
two. Pioneer Valley Transit Authority is the only agency anywhere using it to
declare that cEMV is *not* supported, which is a genuinely useful thing to publish
and which nobody else does.

Set that against the agencies known to accept contactless bank cards. New York's
MTA has run open-loop since 2017 and Chicago's CTA
since 2013. Neither says so in any feed. WMATA is silent after [more than 6 million
contactless
trips](https://www.wmata.com/news/paying-for-the-bus-just-got-easier-tap-ride-go-contactless-payment-launches-on-metrobus.html).
So are RTD, LA Metro, KCATA, MBTA, DART, Miami-Dade, San Diego MTS, and BART. A
rider can tap a bank card at every one of them, and no trip planner can learn that
from the data.

The inverse is the more interesting half. Several operators that do declare cEMV,
including C-TRAN, Spokane, Madison, Cleveland, Long Beach, and Rochester, appear in
none of the trade-press roundups of open-loop deployments. For the eleven agencies
filling the field in, the feed is a better record of who takes bank cards than the
press coverage is.

One caveat belongs on this number, and it comes from the data itself. SEPTA
publishes two live feeds in the catalog, one for bus and one for rail, and they
disagree about which fare medium is the bank card. The bus feed labels "Contactless
Payment" as type 3, which is correct. The rail feed labels "SEPTA Key," the
agency's own closed-loop card, as type 3, and puts "Contactless Payment" at type 1,
the code for a physical paper ticket. Same agency, same catalog, contradictory
answers. Where a field is this sparsely used it is also inconsistently used, so
treat sixteen as a floor rather than a measurement.

## What to watch

The 2026 cohort launched at adult full fare. The question for 2027 is whether they
add the eligibility layer or leave riders who most need a discount on the old card
indefinitely, which would make open-loop a convenience for people who already had
options and nothing for anyone else.

The data question is narrower and easier to fix. `cemv_support` costs an agency one
column in a file it already publishes, and it is the difference between a trip
planner telling a visitor "you can tap your card here" and telling them nothing at
all. Agencies spending years on fare payment modernization are, at the last step,
declining to mention it.

We will re-run the census when the next wave lands. If the field is still in single
digits by then, the specification anticipated a need the industry has not felt yet.

## Frequently asked questions

### How does open-loop transit payment actually work?

The reader authenticates the card offline, hashes it, and checks the hash against a deny list stored on the terminal. If the hash is absent the gate opens, before any authorization has been requested and before any fare has been calculated. Taps then accumulate over a travel period, usually 24 hours. At the end of it the back office reconstructs the journeys, prices them, and submits one combined authorization and capture for the total.

### Why does my transit charge not match the trip I took?

Because the charge is aggregated. The back office adds up every tap in the travel period and submits a single transaction for the total, which is why one line item on a statement can cover several trips and can post a day or more after the ride.

### What is a deny list in transit fare collection?

A deny list is the set of card hashes a reader will refuse. A card lands on it when the payment for its accumulated fares is declined. The list is pushed back out to every reader on the system, on Mastercard's Pay As You Go model every 20 minutes, and removing a card requires a successful debt recovery transaction.

### Why can't I get a discount fare with a contactless bank card?

A bank card identifies an account, not a person, so the system has no way to know a rider qualifies for a senior, youth, or low-income fare. Agencies that support discounts on open-loop require the rider to register the card against an eligibility record first, which is what OMNY registration and California's Cal-ITP Benefits flow do.

---

Source: ITS Feed, https://its-feed.com/articles/open-loop-tap-to-pay/
ITS Feed is an independent editorial site on the data and technology layer of transportation, published by the team at Veodyn. Figures trace to the sources linked inline.
Site index for agents: https://its-feed.com/llms.txt