This is like a 100 bytes, a qr code can be over 2kb
This is a cheap plastic substrate with ink printing over the top. A qr code is just ink - or some other even cheaper printing process if you prefer.
This needs a specific ticket technology supplier over the next 10’s of years. QR codes can be drawn on screens or printed on paper and you can change suppliers for every component - from mobile phone apps to paper type to physical printer and reader devices - until your heart’s content over the next years. That flexibility can’t be underestimated in a space like public ticketing over decades.
Issuing replacement tickets needs physical presence to collect the ticket, vs qr code which can be emailed, sent on whatsapp, shared as a screenshot or photo if you need to, but of course you can still exchange physical paper qr codes if you prefer.
The rfid reader for these are cheap and durable, the optical reader for qr codes can be almost as cheap and almost as durable but not quite, the rfid wins this one point by a small margin.
I've worked in public transport ticketing for the past 30 years including the first system outside Japan (Hong Kong's Octopus).
The problem with QR codes:
1. If they're printed, they can be copied.
2. "Dynamic" QR codes can be screenshot.
3. They're read-only (by definition)
4. Readers are slow, require good orientation by the user.
NFC is good because it's read/write, has a ~10cm range, the larger cards can hold up to 4K of data, the ultralights can replace single journey tickets and can be recycled like magnetics being captured at exit.
I don't think the suggestion is the QR code contains the ticket info, but that the QR code is the unique tag into the back end virtual ticket system. 1 to 3 are not relevant in that context, and 4 isn't borne out in my experience with modern readers (they're used in the bar code mix at parkrun and they read time is vanishingly fast with a smart phone, generally better than barcodes). The number of bits might increase the difficulty if capturing the code, but I would very surprised if a fast, robust system can't be built.
The huge disadvantage of NFC in this context is the electronic waste necessarily produced.
NFC doesn't necessarily create any additional e-waste. In Chicago we have an NFC system, and people typically just link their phone to their account and use that to pay.
I still use a physical card - so that I have a backup option in case something happens to my phone - but even there the volume of waste is trivial. I've had my current transit card for ages, and it doesn't expire until 2037. It's possible that the only technological decision I've made that generated less e-waste was deciding to splurge on a mechanical watch instead of a quartz model.
Those are more for single rides by people who rarely or never use the transit system. I've had the same Carte Opus for years and just bring it with me and refill whenever I visit Montreal. And the disposable paper cards are being phased out. I'm not sure when the rollout will be, but Montreal is currently working on upgrading the system to allow people to just tap-to-pay at the turnstiles using their phones or compatible credit and debit cards.
Which is not something that you could do with a QR system. I don't know that anything is inherently wrong with QR codes, but they do seem to be a choice that's more appropriate for countries like China where the existing electronic payment infrastructure uses QR codes. In North America, by contrast, things have generally settled on NFC, and I think that that reason alone probably makes NFC the better option for North American transit systems.
> Montreal is currently working on upgrading the system to allow people to just tap-to-pay at the turnstiles using their phones or compatible credit and debit cards.
> Which is not something that you could do with a QR system
I've got several apps that display QR codes on the screen for an external reader. One of them is for my health insurance id card (a simple 10 digit number), another shows my COVID vaccination status (this one is complicated, and I'm not sure why they used a QR code for it. It must include batch identification and other information given the size)
By tap-to-pay, I mean you need no special apps, you need no special accounts, any of that. You can pay with any physical credit or debit card that supports tap-to-pay, or you can use any credit or debit card you have loaded into your phone.
With a QR code like that, people still need to install an app, set up an account, etc. It's just a lot more friction. In cities where I can tap-to-pay, getting set up to ride a bus or train for the first time takes literally zero time; I'm already set up. If I need anything special - apps, accounts, system-specific QR codes, etc - then the setup time instantly goes up to a minimum of 10 minutes. It's a relatively large barrier to entry for infrequent riders, and ultimately serves to discourage use of public transit.
Really? Setting up contactless payment is quicker than having a QR code image? I use QR codes on the UK train system and I don't have any special apps. It seems to integrate with Google wallet too, which surprised me.
The point of the disposables is that they use the same technology (NFC/RFID) as the more robust long term multi-use NFC cards.
So if you're replacing an existing magnetic system, you can reuse the magnetic transports (belts/motors etc) for single use, including capture-at-exit and recycling for single journeys, while also adopting the NFC for multiple use.
In China, QR Codes are used for public transport too, and I found them just as fast as NFC readers (and faster than the slow readers used by the NS in The Netherlands)
Until you go to another city and discover that the local bus company has decided that instead of just letting you pay by Wechat pay or Alipay, you need to install their proprietary app to generate the QR code for the bus to scan, at which point the app then just turns it into a Wechat pay or Alipay transaction at the end. No benefit to the user, it just allows the bus company to extract all your PII in the process. Actually, they're not all proprietary apps, but there are several from competing companies, and you have to use whichever one the city has chosen.
Actually, I think part of the reason is that so they know who's on the bus in case it's involved in an accident, because if you buy a ticket from a bus station for a "short distance" (so out of the city, but within about 40km), you also have to provide them with a phone number even though they never call you or send you an SMS using that number.
The time to process a payment at a retail outlet is ~1s+, the time required for public transport is usually <0.5s including mechanical release of barriers etc.
You can fail open. The QR code contained a signed ticket ID and expiry. You locally validate the signature and expiry and remotely attempt to validate reuse. If the remote validation is slow or fails just accept the ticket and log it.
1. Thats ok. If you’re expecting your rfid tokens not to be copied just because it seems inconvenient to do so, you’re in for a surprise! Your ticketing system cannot assume tickets in any form cannot be replicated- they can be and if you introduce such a vulnerability in your system, you will lose revenue
2. As per 1, no issue
3. That’d be a great feature if true, I’m all for immutability. However , qr codes can be defaced easily, hopefully the built in checksum defend against that. a more likely threat your system needs to defend against is that new qr codes can be generated extremely quickly
4. Both systems are the same speed, both systems require accurate targeting by the user, an rfid token slightly askew of the reader will not read since it won’t be able to influence / absorb the generated rf - most of these systems work by providing power to the rfid token and it communicates back not by transmitting its own signal but by exerting influence on the signal it’s receiving. It’s a very very low power interaction and very sensitive to positioning
A better problem than 4 is that you entail staff overheads with a visual system to keep them clean.
Read / write is a bad feature, you will lose ticket sales.
Recycling these is not practical. Direct reuse risks jamming the vending machine (used tickets end up subtly bent, very hard to reliably deal with), actual recycling isn’t viable, the energy required and emissions produced exceed that of creation of a new card from raw materials.
> Your ticketing system cannot assume tickets in any form cannot be replicated- they can be and if you introduce such a vulnerability in your system, you will lose revenue
Yes, the question is not whether such system would be abused, but how much. But this is in the end what businesses care about.
Will QR codes be abused more than NFC chips? Likely yes.
Will it produce a larger financial loss than the cost of the NFC chips?
Can I mitigate these losses by a centralized validation system (each terminal needs a network connection with low latency guarantees)? Sure, but how much will it cost?
40 years ago we had a read-write system based on mechanical trimming of a piece of card and a physical time stamp[1]. It's absolutely possible to roll out a system to keep track of journeys that doesn't require fancy embedded ICs.
1. NFC tickets with embedded security are robust against replication, at least to the extent required for transit.
On 4, QRs are substantially slower to be read and decoded. NFC/RFID have a range of ~100mm and the field shape is dependent on the antenna design, however it is way more tolerant than QR using IR/laser. As for "entail staff overheads", we are talking about systems that process thousands of taps/day through single gates. Anything that reduces maintenance requirements is absolutely a priority.
As for "read/write is a bad feature", I don't really understand your point.
Ultralite RFID/NFC tickets are routinely recycled where they are used to replace old magnetic systems that have belt transports for the magnetic tickets. The read/write heads of the magnetic stripe are replaced with NFC readers but the belt transport and capture mechanisms remain.
I’ve found NDEF cards that can hold 16KB & 32KB, even as much as 64KB. That may be too much capacity for ticketing but it blows QR codes out of the water
That is the issue. If it was just a matter of a unique identifier, then a read only token would be fine.
However, for most transit, there is some form of "check in/out" (either through barriers/gates or via validation/inspection). This is combined with rules about "antipassback" (ie one user passing the token back to another to reuse), as well as "total time in system" (ie to avoid people staying in the system all day).
There are also rules that take into account entry/exit times (eg peak/off-peak), entry/exit locations (eg core/non-core zones) etc.
All of these rules require either:
a) An always online set of validators to be able to contact the backend that is maintaining the information, or,
b) a way to record the information on the token so that it is physically transported from one validation location to another.
It also is needed for inspection purposes during a trip.
>> there’s less need for centralization of data storage and code logic
You make it sound like less moving parts are a bad thing :-)
I know what you're getting at though - the decentralized tolerance of network partitions and the ability to provide higher availability and faster decision speed at the entry barrier.
The system design constraints are hard but not impossible, my back of napkin maths says 5k/ticket scans per second with 99th percentile latency < 1000ms not only satisfies every use case that exists today but allows for 3x population growth beyond!
There's a few things in your favour when designing this system though. For example, in the case of network partition, you have geographic locality so a pen drive delivered a couple of times per day is likely feasible.
The usual maximum time allowed for tap->barrier open is a maximum of 450ms. That includes all read/write times for the token, display changes, fare calculations and deductions, all business rule validation (eg hotlisting stolen tokens etc).
The system I recently put in allowed for that 450ms, the time broke down to:
During peak periods the usual rate expected is 30-40 passengers through a gate/minute, which includes all of the time above, plus the passengers actually walking through the barriers (usually ~2m).
Not relevant. The maximum specified by contract is usually 450-500ms.
The barriers at rail stations have to have a defined maximum throughput of passengers, because it affects safety during emergencies etc. Most barriers are required to maintain somewhere between 30 and 45 passengers per minute.
Yes they can "default be open" and usually have emergency modes that disable validation entirely, but the speed during peak hour periods has to maintain the passenger flow.
Usual requirement is <500ms from tap to passenger through the barrier, which includes not only the validation/fare deduction etc, but also the display and barrier unlock.
Lots of others mentioned key downsides of QR codes that make them generally unsuitable for this purpose (they are stateless, trivially copied, easily fouled from repeated use, too slow because of fundamental optical constraints, require a 100% available centralized ledger/don't work while the reader is offline, etc. etc.) but I'd just point out that decades of R&D have gone into making these systems work well at scale at the busiest train stations in the world, and QR codes came up short. Here is a glimpse of early R&D efforts that went into this: https://www.jreast.co.jp/e/development/tech/pdf_6/tec-06-40-... - it covers some of the technical requirements these systems fulfill.
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.
One advantage of the RFID, is that you can modify the ticket while using it. This is actually what made Montreal choose that solution. There's no internet connection to validate the tickets, they just update the ticket to say they are used.
I would have said that make it much more resilient, but I have seen so many buses that couldn't accept fares... I'm not so sure if it's the case.
The two big things that QR codes have going for them is that they're cheaper to make and that they can be trivially displayed on a smartphone screen.
Contactless ICs are more powerful in every other aspect: They're rewritable (allowing reusable tickets), they can support challenge-response authentication (allowing secure offline usage, which in turn makes for faster transactions at the gate), and they're much less finicky to scan in my experience.
I was in Rotterdam recently. Their metro system uses multiple approaches, some kind of RFID for hard tickets, NFC payment (without a ticket at all) and QR codes for time-limited tickets that you can buy in a phone app.
Getting those QR code readers to read the QR code was a nightmare. Almost all the cameras have heavily scratched protective windows in front of them, which makes the reading process a struggle of trying to find a working angle. Of course the scratching is vandalism, but subway systems must be robust against vandalism, cause it's something that happens and must be expected.
I switched to per-transit payment via NFC after using one of the time-limited tickets and realizing that you need to consider yourself lucky if you find just one working QR code reader at most stations. NFC worked like a breeze.
When I lived in Shanghai 6 years ago they were trialling QR for the metro. It was really bad, always huge queues with people struggling to get the right angle/illumination/whatever to make it scan. I’ve never seen similar issues with contactless methods and in fact I think SH subsequently moved to them. The amount of data stored seems pretty trivial to scale if necessary.
When I was in Shanghai this year I used a metro QR code via AliPay, and it seemed everyone else did too. There didn't seem to be any issue with scanning them so I guess everyone got used to that. There was however a queue by the security theatre bag scanning device at every single ticket gate.
Interesting, I didn't think you could pay directly via Alipay or Wechat.
Most cities you can use chengchema/dachema mini-apps in Wechat to generate the QR codes, but also all the old smartcards I had from previous trips worked in their various cities (but only work in that city) and usually had slightly cheaper fares than the QR-code ones, which were the same as the cash price to buy a single-use ticket.
But yeah, the bag checking is annoying in China. Shanghai is very relaxed compared to everywhere else - most places you even have to have your water bottle scanned to make sure it is actually water, or else take a sip from it.
Your comment sounds good for overland rail, bus, event tickets, airlines etc and indeed QR is common.
But for subway/metro, during rush hour throughput it is important to able to tap an RFID almost instantly. QR is too slow and error-prone for subway/metro.
The world (including Montreal - these tickets are going away) has converged on credit card / phone / top-up charge card for that reason.
QR Codes are fine for one off event entries. For a transport medium that requires fast high volumes of people to go through its an awful idea. QR Code reading is slow, you can't avoid that.
Its slow because it's read by a camera. That takes extra steps, and like you mention, lighting conditions. A QR code has to be detected, read and decoded, and thats after the image is processed. An NFC is orders of magnitude faster. Heck even an old school magnetic strip is faster than a QR code.
A better application for QR codes is scenarios where it doesnt matter that its slower. Airline checkins, concert tickets, etc work well, a busy subway where people are queueing to get through a barrier as quickly as possible is one of the worst places to use it.
When I travel to work, the time from me rotating my phone screen to present it to the qr reader window on the gate until the time that the gate opens is <1 second always. I’ve never encountered a delay, it doesn’t seem all that sensitive to what angle you hold your phone at either, it’s only sensitive to distance I’ve found, you need to hold it no more than 2 inches away.
Separately we have revenue enforcement patrols with handheld scanners. The time from the red flash of the scanner on my screen (triggered by the person holding the scanner, it’s not constantly scanning) until the beep for ticket result is < 200ms, I.e. it feels very much almost instant but with a little perceptible delay.
RFID is less angle dependent on reading well quickly. There are delays boarding planes trying to get everyones phone to scan while the NFC seems to work a bit better just hold it up to the reader and walk through.
My understanding is that the STM (runs the Métro) likes to keep fares on the actual paper tickets or rechargeable card, rather than in some central database.
The paper tickets can hold many fares, including unlimited evening fares or two day fares. I believe this would be hard to pull off with QR codes without having to keep track centrally.
If it was a short-lived QR code generated on your phone, then maybe. But the whole point of MIFARE Ultralight EV1 cards is that they can't be cloned. It's for repeated use, not for printing and using once.
This is like a 100 bytes, a qr code can be over 2kb
This is a cheap plastic substrate with ink printing over the top. A qr code is just ink - or some other even cheaper printing process if you prefer.
This needs a specific ticket technology supplier over the next 10’s of years. QR codes can be drawn on screens or printed on paper and you can change suppliers for every component - from mobile phone apps to paper type to physical printer and reader devices - until your heart’s content over the next years. That flexibility can’t be underestimated in a space like public ticketing over decades.
Issuing replacement tickets needs physical presence to collect the ticket, vs qr code which can be emailed, sent on whatsapp, shared as a screenshot or photo if you need to, but of course you can still exchange physical paper qr codes if you prefer.
The rfid reader for these are cheap and durable, the optical reader for qr codes can be almost as cheap and almost as durable but not quite, the rfid wins this one point by a small margin.