Too many times I have been stuck in 15-20 minutes queues to buy those tickets and you cant refill them with an app... Plus south shore and north shore have they own system it's a mess.
- Full offline support (i.e. both the reader and payment device don't need network connectivity), making the system more resilient
- Symmetric cryptography and highly optimized transaction flow, making reads more reliable and allowing faster customer flows through transit gates
- Upfront transparency about charges, monthly passes, capping etc. – you immediately see your balance left after tapping.
- No "transaction spam". This is more on my specific transit provider (NYC MTA), but I'm really not a fan of getting an individual credit card charge for every. single. tap. It can't be cheap in terms of fees for the operator either! At least other systems, like TfL in London, aggregate taps over a day, but it's still not great.
Singapore's public transit agency recently attempted to switch from a stored value based model to an exclusively account based one, but had to backpedal quickly due to public outrage about the move.
Ideally, a system supports both payment methods: Open-loop payment cards for infrequent users, and stored-value cards (both physical and in digital wallets) for heavy users and anybody else that prefers them. But realistically, maintaining both is too much of a burden for many transit agencies.
I would argue that contactless debit/credit card or mobile wallet taps are substantially more convenient for tourists and occasional users – if you are fresh off the boat (or off the plane – for a more modern twist), not much can beat the convenience of turning up at the turnstile, tapping on and getting on with the trip on the local public transport network and tapping off at the end of the trip.
No need to look for a place that sells local rechargeable or disposable NFC cards, having to be aware of a low balance, looking for a place where the card can be topped up, actually top them up and stuff like that. For frequent travellers, it also entails having fewer non-portable mass transit payment cards to carry.
Bonus points: debit/credit card/mobile wallet payments also eliminate the problem of the discovery and consolidation of lost balances when a card gets lost, and it reduces the environment impact (manufacturing + energy consumed during the process) and the wastage (the disposal or, rather, the lack thereof) that disposable NFC cards inherently possess.
That is what Sydney (the one that is not in Canada) has done: they went straight from prepaid paper tickets to their own rechargeable Octopus/Oyster style cards (with the name also beginning with an «O» – Opal) followed by enabling debit/credit card (Visa/MC/AmEx) and mobile wallet NFC payments later within the larger metropolitan area public transport network on buses, ferries, trains and trams.
Convenience, as always and of course, comes at the expense of privacy, though.
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.
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.
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
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.
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.)
In the old days you’d nominate a specific station, and the credit would be transferred to the card the next time you tapped in at that station.
But now days I don’t think you need to do that: presumably it maintains the balance primarily on the server side now rather than on card.
I remember using that feature in the SF bay area, and while it took a day for the top-up to actually propagate to all readers, it even worked on buses, so they must be uploading that data everywhere.
That type of connection needs to be there in any system that supports lost/stolen card value recovery, in any case, since that's how card block lists are distributed.
But yes, for speed/redundancy they are still probably using the stored value balance too.
TfL likely need that mechanism primarily to synchronize the list of blocked open-loop bank cards with unpaid balances to all readers. Faster Oyster transaction list updates and any-station remote top-ups are probably just a side effect of that.
Clipper doesn't (yet) support open-loop bank cards yet, so for them, it's probably enough to update more remote readers every time the bus goes back to the depot, for example.
There’s the OMNY card, and I believe the original plan was to outsource sales and top-ups to third-party stores, but lately I’ve also seen some vending machines for that in some stations, so maybe they’re going back a bit on that idea.
You can now refill the rechargeable OPUS cards using an app.