4 ms·

> […] dedicated card purse-based systems can be better for regular commuters. I suppose it is a matter of personal or circumstantial preferences so I won't go

> […] dedicated card purse-based systems can be better for regular commuters. I suppose it is a matter of personal or circumstantial preferences so I won't go into that, but through reading this discussion, I have learned that, e.g. the Boston MTBA's CharlieCard, have an expiry date and has to be replaced in person. From the regular commuter's point of view it is a nuisance of epic proportions – to turn up at a bus stop or a station only to find out they are unable to pay because their dedicated card has expired. The commuter is only interested in the act of paying the fare and not in complexities of the local mass transit system's payment network shenanigans. I also can't help noticing that the wallet (the purse style) making business has taken a hit in recent years due to the rapidly decreasing circulation of cash and the rise of mobile wallets. Many people now leave their homes with their smartphones and keys only. Eventually and inevitably, all cities will embrace either the integration with or adoption of mobile wallets, but that will take a while depending on how well each government funds its local public transport agency.

lxgr 2y ago
Mobile wallets are not a contradiction to dedicated transit cards, though! Apple Wallet supports transit cards for dozens of transit systems, and most of them have some associated app to allow managing monthly passes or topping up the balance. Arguably, that's the best of both worlds.
- inkyoto 2y ago
  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
  - lxgr 2y ago
    Definitely – the challenges and cost of maintaining these individual systems should not be underestimated. But practically, a lot of them are run by a small set of contractors anyway, not any government entity directly. These only need to integrate with wallet providers once; beyond that it's just a matter of contract terms and uploading a few new assets to Apple's and Google's servers. (I believe Apple can even launch new transit cards without an iOS update these days.)

lxgr 2y ago

Mobile wallets are not a contradiction to dedicated transit cards, though! Apple Wallet supports transit cards for dozens of transit systems, and most of them have some associated app to allow managing monthly passes or topping up the balance. Arguably, that's the best of both worlds.

inkyoto 2y ago
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
- lxgr 2y ago
  Definitely – the challenges and cost of maintaining these individual systems should not be underestimated. But practically, a lot of them are run by a small set of contractors anyway, not any government entity directly. These only need to integrate with wallet providers once; beyond that it's just a matter of contract terms and uploading a few new assets to Apple's and Google's servers. (I believe Apple can even launch new transit cards without an iOS update these days.)