Why can a transit gate open without unlocking the phone?
Because that credential is allowed to answer without the usual check. The permission is declared by the service that holds it and constrained by the platform: whether the screen has to be on, whether the device has to be unlocked, and whether a wallet is watching the reader to decide.
The permission is declared
On Android, a card emulation service declares whether the device must be unlocked before it will handle a terminal's commands. The Android host card emulation guide documents the attribute and its consequence: with it set, tapping a reader prompts the user to unlock and then to tap again, because the phone was moved away from the reader to be unlocked.
A transit service is exactly the case where that behaviour is unacceptable, so it declares that it does not need the device unlocked, and the platform lets it answer from the lock screen.
On the other platform the same idea appears as a mode a pass can be put in, and a pass whose credential lives in the payment chip, the secure element pass, is the object it applies to.
Screen off is a separate question
Unlocked and awake are not the same condition, and the guide separates them. From Android 12, an application can enable payments with the screen off by setting the attribute that required the screen to be on to false.
Underneath that sits a device setting the same guide describes: with Secure NFC on, every card emulator, whether it runs in the operating system or in a secure element, is unavailable while the screen is off. With it off, credentials held in a secure element still answer with the screen off, and the ones emulated by an application do not.
That is the real explanation for a behaviour people describe as random: two phones with the same wallet behave differently at the same gate because one has that setting on.
What a phone does when it has no power at all is a different matter again, and the phone off page covers it.
What recent platforms added
From Android 15, the guide describes an observe mode: where the device supports it, the default wallet watches what the reader is doing before anything answers, and it controls whether a transaction may proceed. A wallet may still require an unlock if it did not recognise the reader's polling pattern, and reader manufacturers are encouraged to emit patterns a wallet can recognise.
The practical effect is that the decision moves from a static declaration to something closer to a conversation: the phone can tell a transit gate from a shop terminal before deciding what to present.
It also explains why the same phone can open a barrier untouched and ask for a face at a till.
What it costs you
A credential that answers without verification is a credential anybody holding the phone can use at a gate. The trade is deliberate: a fare is small, a queue is expensive, and the operator accepts the exposure.
That is the same reasoning the limits page describes for a card, with the ceiling set by what a journey costs rather than by a banking rule.
It is also why the express arrangement is offered for transit and not for the rest of a wallet, and why a lost phone matters more than a lost ticket, which the cluster on losing a phone takes up.
Frequently asked questions
Why does my phone open a gate but ask for a face at a shop?
The transit credential is allowed to answer without verification and the payment one is not, and recent platforms let the wallet tell the two readers apart.
Why does it work with the screen off on one phone and not another?
A device setting decides. With Secure NFC on, no card emulation answers with a dark screen, whatever the application declared.
Can any application do this?
It can declare that it does not need the device unlocked, but transit arrangements are agreed with the platform and the operator, not simply switched on.
Is it safe?
It is a deliberate trade: anyone holding the phone can pay a fare with it. The amount at stake is a journey, and the alternative is a queue at every barrier.