How does a phone pay a transit fare?
In one of two ways. The gate accepts a bank credential and the operator prices the journey afterwards, or the operator has issued its own credential into the phone and prices it there. They feel identical at the gate and differ in almost everything behind it.
Two arrangements
A fare can be collected by accepting the same credential a shop accepts, and working out afterwards what the journey cost. Or by issuing a credential that belongs to the transit system, held in the phone the way a card was held in a pocket.
Both end with a phone held against a reader for a fraction of a second. Everything else, who bears the risk, what happens with no network, what a refund looks like, follows from which of the two it is.
This page separates them. The rest of the cluster takes the consequences one at a time.
When the gate takes a bank credential
The gate behaves like a payment terminal with an unusual pricing rule: it accepts the credential, records the entry, and the fare is computed later from the journeys that credential made. What the reader receives is what any terminal receives, which the terminal page describes.
The credential is the device, so a phone and a watch used on the same journey are two different travellers as far as the system is concerned, which the two cards page explains and which is the commonest way to break a daily cap.
The verification question is the interesting one: a gate cannot wait for a face check at every barrier, which is why the platforms provide a mode where a transit credential answers without the usual unlock, covered by the express page.
When the operator issued the credential
Here the phone holds something the transit system made: a season ticket, a stored balance, a pass. It is provisioned into the device rather than copied from a card, which is the same rule as everywhere in this section and the reason a plastic card cannot simply be duplicated into a phone, as the transport card page sets out.
Apple models this explicitly: a pass whose credential lives in the device's payment chip is a secure element pass, a different class of object from an ordinary pass. On Android the equivalent is a service holding the operator's application identifiers, either in a secure element or emulated by the wallet.
The operator keeps the pricing, the entitlements and the customer relationship, and pays for the provisioning arrangement to exist. That is the trade against the bank credential model.
What the gate demands of both
Speed. A barrier has a fraction of a second while somebody walks through, which is why the fast tap page matters more here than anywhere else, and why gates are tuned for a presented phone rather than a waved one.
A decision without a network, at least sometimes, which the offline page takes up for buses and which applies to any gate whose line is down.
And one answer rather than several. A phone that presents a transit credential and a wallet full of other cards has to produce exactly one, which the wrong card page covers when it goes wrong.
Frequently asked questions
Is a phone accepted everywhere a card is?
Where the gate accepts bank credentials, usually yes. Where the operator issues its own, the phone has to have been provisioned with it.
Does the fare come out at the gate?
With a bank credential the journey is priced afterwards from what that credential did. With an operator credential the pricing happens in the system that issued it.
Can I use a phone one way and a card the other?
You can, and the system sees two travellers, which is how daily caps and return fares get broken. Use the same device for a whole journey.
Why is the gate so fussy about how I hold the phone?
It has a fraction of a second as you walk through. Presenting the phone flat and still beats waving it past the reader.