How can a bus accept a tap with no connection?
By deciding locally. The validator checks what it can against a list it already holds, records the journey, and sends the batch when it next has a connection. Everything it could not verify at the door is a risk the operator has decided to carry.
Why offline is the normal case
A bus moves through tunnels, cuttings and dead spots, and a door has to keep working through all of them. Even a fixed gate loses its line occasionally, and an underground platform is the ordinary case rather than the exception.
So a validator is built to work with no network and to reconcile later, which is the same constraint the offline page describes for tags and the no data page describes for phones.
The passenger side is unaffected by design: the tap looks identical whether the validator is connected or not, and that is the whole point.
What a validator decides alone
It can authenticate the credential in front of it, which is a cryptographic exchange rather than a lookup, and it does not need a network for that.
It can check what it already holds: a list of credentials to refuse, a set of fare rules, a record of whether this credential has been seen on this vehicle already.
What it cannot do is ask whether the account behind a bank credential still has money in it, or whether a pass bought two minutes ago on a phone exists. Anything that depends on the world outside the vehicle waits for the connection.
Where the credential is the operator's own and carries a stored balance, more can be settled at the door, because the value is in the card rather than in an account elsewhere.
The risk the operator accepts
Between the tap and the reconciliation, the operator has carried a journey it could not fully check, and a proportion of those will turn out to be unpayable.
That is a commercial decision rather than a technical failure: the alternative is refusing passengers whenever a connection drops, which costs more than the losses. Every deny list is a compromise between how fresh it is and how often a vehicle can be updated.
It is also why a credential that failed somewhere else can still work for a while, and why it eventually stops: the list reached the vehicle.
What it means for the passenger
A tap that was accepted on board is not a completed transaction. A fare can appear later, a refusal can be delayed, and a journey can be priced hours after it happened.
A phone with no signal is not the problem people assume either: the credential is in the device and the exchange is local, so the phone works underground exactly as it does on the street, which the express page covers for the unlock side.
What does matter is battery, since a phone with none presents nothing at all, and the phone off page sets out what survives a flat one.
Frequently asked questions
Does my phone need a signal to pay a fare?
No. The exchange with the validator is local, so it works underground and in a tunnel exactly as it does anywhere else.
How can a bus refuse a card it cannot check?
It holds a list of credentials to refuse and applies it locally. The list is only as fresh as the last time the vehicle was updated.
Why did a fare appear hours later?
The validator recorded the journey and sent it when it had a connection, and the pricing happened then.
Can a blocked card still work on a bus?
For a while, until the refusal list reaches that vehicle. The operator accepts that gap as the price of accepting passengers with no connection.