The problem with QR codes is that they are read-only.
I don't know about Montreal, but Moscow public transport uses similar paper tickets, also Mifare Ultralight, except you can get them for different number of trips. When you use your ticket, the turnstile or validator would increment those one-way counters so that the next one would know how many trips you have left. You can't do that with a QR code without either the reader or the user's device having a persistent internet connection to some sort of central server that would keep track of all tickets, which is impractical.
NJ Transit uses QR codes for all train tickets and it works well enough. It's not quite as seamless as a tap card but NJT has moved largely to mobile ticketing and they're in the odd position of having to scan tickets both at turnstiles and by train crew (handheld scanners); cards would be awkward in the latter case. The paper tickets used to have magstripes but once they adopted QR codes for the mobile app, the tickets lost the magstipe and gained a printed QR code.
So the central server model is practical. The user's device has to have an internet connection at some point to activate the ticket within a reasonable period before using it but the connection doesn't have to persist after that. I don't know how their handheld scanners work in the Hudson River tunnels where there is no cell service but they do, so long as the user activates their ticket before the train departs.
Do you mean it would be hard for staff to scan cards? Here in the Netherlands both qr and cards (travel cards + bank cards) can be used at stations, and are read by the staff on the train.
Once I searched how Japan do the synchronization of the data in the IC card because I can't imagine how they handle all of the traffic for millions of people especially in the rush hour.
So the solution is the transportation card is writable, and each train station acts like a small data center. They sync the data periodically to the main data center.
I think the syncing tech is getting better, Japan train companies are going to experiment with QR code soon. So read only is feasible.
> So the solution is the transportation card is writable, and each train station acts like a small data center. They sync the data periodically to the main data center.
That's also how the two subway systems I'm most familiar with do it here in Russia. In both Moscow and St Petersburg, the data stored on the refillable tickets (Troika and Podorozhnik respectively) was thoroughly reverse engineered. People who did it, of course, tried to write them too — for example, you'd make a dump, enter a station, then restore the dump with your old balance. It worked, but only for a day or two, after which the card number was added to a blacklist that all turnstiles check cards against. The conclusion was that there's a server on each station that turnstiles talk to, that syncs with some central server each night (when the subway is closed), where all system-wide transactions for the day are collated, and if anything is off, the card is blacklisted.
Oyster in London works like this too so I’ve heard. Some terminals (e.g. those on buses) are offline until the terminal is docked and connected to the main centre.
The Helsinki metropolitan area public transit system "HSL" used to be like that.
Bus passes were first mifare and the DESfire after some upgrades, but the readers in the busses contained the transactions and worked offline.
If they got filled up the the standard practice was free fares. :)
Japan railway companies in Kanto region are moving to QR code for individual ticket in 2027.
The bulk of the ticket will still be the Felica card though, because as far as I know neither the QR code or EMV open-loop system can handle required throughput of 60 persons/minute/gate.
I think semi-persistent internet is not such a big deal for a lot of providers. For Opal here in Sydney AU it uses a connection for some features. Cards can be anonymous or assigned to an account, the account shows all your trips online, so there's some required connectivity for that. The cards have a smart chip, but credit cards or phones can now also just be tapped directly, so it needs to match up when you tap off and determine where you started and how much to charge. This includes buses, which use 3G IIRC, and may drop offline sometimes.
To support the above, they did away with multi-trip tickets like you describe. It instead tracks and discounts once you hit a weekly limit (yes, you have to give up your privacy for this with an account or use your credit card directly). Not great for intermittent travel.
For systems like this the question is: if the internet is down and a few people get a free trip, does it really matter? You don't always need 100% accuracy if it makes everything else simpler, like removing paper tickets, printers, litter, etc.
Fun tangent: I hit a bug in Opal recently with the stored value cards. I was able to obtain a balance that read out higher on the exit turnstile than on a top-up machine. I'm pretty sure this was related to a recharge that failed and then eventually succeeded. Multiple top-ups later and the difference seems to persist.
You're correct, there are a bunch of different ticket options. Not sure about how it's actually implemented, though.
Slightly tangential, but when I was in Montreal, I was blown away that you just purchase a ticket from a machine and you get a printed out ticket with an NFC chip inside. Not my favourite part of the trip (Montreal is beautiful!) but definitely a cool piece of technology to see being put to such a mundane use.
I am not sure which part is impractical. In India we already use QR code for metro tickets. The system design is definitely different from one mentioned and mimics more of how airport tickets work.
How does the system know that the ticket was already used?
The thing with plane and long-distance train tickets is that you buy them for a specific route. So all the checking only needs to be done at your departure station/airport, the code for which is encoded in the ticket, and the rest of the system doesn't need to know anything about it. But you can't do that with city transport. When there aren't multi-use tickets, people would often buy multiple single-use ones at a time and use them as the need arises, without knowing in advance when, where, and from where they'll be going.
Fair enough. I went through qr code of my previous metro ticket to see what info they encode. It is non standard so there were
- some hashes
- type of ticket, in my case single use,
- time of issue,
- valid upto time, approx 10hrs, approx journey time was only 30 min
- ticket id
- I could not directly see source/destination address, but it is my hunch that atleast the destination address is encoded
Now this one time ticket needs to generated before entering the metro station and the qr code is scanned at * both entry and exit*.
I think the entire system works on daily rotating ticket id validated using unique hashes where a ticket validity period is tracked. I think this should be enough to ensure non-reuse of same ticket.
The caveat is, I have always only bough one time ticket which is the only mode allowed in qr. For daily traveller's, they need to buy token/card which is NFC based.
Thinking of it, QR codes make sense for when you buy a single-use ticket at the station with the intention to use it immediately.
We actually have this for suburban trains, it's just a receipt with a 1D barcode on it. You use the barcode to open the turnstile (on some stations where they are installed), but otherwise the tickets are checked by controllers that occasionally go through trains.
For getting around a city though, I don't see much of a good use case. In my city, if you're here for at least several days, you're expected to buy the refillable card. If you're only here briefly and only need to use the metro a couple times, it's 1.5x more expensive but you'd buy tokens or tap with your bank card.
The system can just keep track of whether the ticket has already been used before. You don't have to store the information on the ticket itself. You can store the information on a central server, connected to all the gates.
The ticket itself just has to encode an ID, and then the central database contains an entry for that ID that is checked by the gate in real time. When the ticket is scanned at a gate, the database gets updated.
That server would have to process thousands of requests per second during a rush hour with very little delay. In addition to QR codes just being much more finicky than tapping a card or sticking something into a slot.
This is indeed how systems around the world do it for NFC tickets. The problem with QR codes is that they're very easy to copy, so the potential for abuse with this approach is much higher. What's to stop people from using the same ticket on two different stations within the sync period?
The QR code can encode (or the system can track, or both) any combination of origin, destination, expiration (or purchase time + validity period), ticket number, etc. Check with the local server that the ID exists with the given information and that the ticket isn't expired, then allow the user through, and the server marks that ticket number as used. If the origin doesn't match the current station, the ticket is expired, or the ticket is used, don't let the user in.
So you would have to buy a ticket every time you go somewhere. That would work for tourists, sure, assuming there are vending machines that can print those QR codes. But it would not work for locals (imagine everyone buying tickets during a rush hour), and even for some tourists, it would be a nuisance. If you're visiting a city and you know you're going to take the subway N times, you would just buy N tickets, but with this system no such thing is possible.
And what about all those transfer discounts some cities have? Like if you're taking the subway and a bus within some timeframe, you still only pay once.
>You can't do that with a QR code without either the reader or the user's device having a persistent internet connection to some sort of central server that would keep track of all tickets, which is impractical.
This is literally how all of the UK Mobile Train Tickets work. The ticket is a 2D barcode either on screen or on paper. Every gate / scanner operated by a guard records when the ticket has been scanned. They are synchronised and a ticket from being scanned twice. It's not that deep
But that's a train that goes outside of the city or between cities. You usually buy a ticket specifically for the route you're taking so no system-wide synchronization is necessary, only the origin station needs to know that you've used that ticket.
it would be interesting to create a wipe mechanism to erase the existing QR code (may be a belt/sander, or a laser like those rust cleaning lasers), and print a new one on (may be even use the same laser as the wipe!).
IC transit cards in Japan use heat-rewritable ink for something similar.
The ticket vending machines print your monthly transit passes right onto the face of your card at the beginning of the month, and erase it after it expires.
It's not a QR code though. Just human readable text for bus drivers. (Turnstiles in the subway still read the pass via NFC.)
If you really want a system that uses optical scanning and allows one ticket to be used multiple times, just make sure that there's enough room on the ticket for one QR code per trip. When validating, you'd print a new code in free space. You can also either print something over the old one to invalidate it, or just leave it and let the system itself figure out which of the codes is newest.
I don't know about Montreal, but Moscow public transport uses similar paper tickets, also Mifare Ultralight, except you can get them for different number of trips. When you use your ticket, the turnstile or validator would increment those one-way counters so that the next one would know how many trips you have left. You can't do that with a QR code without either the reader or the user's device having a persistent internet connection to some sort of central server that would keep track of all tickets, which is impractical.