Yes, I am in a full agreement on the best of both worlds, with a couple of caveats. Apple Wallet supports neither the Montreal (the subject of this discussion)

Yes, I am in a full agreement on the best of both worlds, with a couple of caveats. Apple Wallet supports neither the Montreal (the subject of this discussion) nor Boston CharlieCard transit cards nor many more. Apple Wallet has promptly shown some transit cards from mainland China, 1x from France, 1x from Hong Kong, 3x from Japan and only 3x (!) from the US (Clipper, SmarTrip and TAP). That is all it supports. Android may support more. The said CharlieCard[0] supports a bespoke mTicket app that is neither integrated with the mobile wallet nor fully supports all modes of transportation in Boston: √ Best for Commuter Rail and ferry riders who don’t often take the subway or bus ∅ No transfers to other modes Which brings me to the main caveat. Compared to debit/credit card payments originated in a mobile wallet, supporting each transit card in existence is an extra effort that places the onus at least on the vendor of the mobile operating system and usually on the local government as well. Generally, governments do not have a good track record at delivering modern digital solutions to their citizens and are inefficient at engaging the smartphone vendors. So at the very least, the governments are slow to instigate a technological change. And, since the onus is also on the government to upgrade NFC readers across the entire network anyway – to support modern ways of paying, the question is which one is more future proof: 1) natively supporting a local transit card at the smartphone level + upgrade the NFC readers to support a variety of NFC protocols, or 2) upgrade the NFC readers to support the debit/credit card and mobile wallet payments only? I am inclined to think that (2) is more efficient and more cost-effective for taxpayers. [0] https://www.mbta.com/fares/charliecard https://www.mbta.com/fares/charliecard