Our new ticketing site is now live! Using either this or the original site (both powered by TrainSplit) helps support the running of the forum with every ticket purchase! Find out more and ask any questions/give us feedback in this thread!
Some interesting job ads on the Rail Delivery Group site:
With over half of all rail tickets now fulfilled via barcode, RDG is investing in a major re-design of its barcode system. You will lead architecture for 'Barcode 2.0', supporting cross-London travel and working closely with TfL. From short-term projects like eTicket On Departure to long-term strategic reform, this is a critical and high-impact role.
This role will shape the next generation of barcode ticketing solutions across rail. You’ll lead the technical strategy for Barcode 2.0, ensuring continuity, security, and alignment with broader retail system reforms.
Lead Solution Architect – BarcodeSalary: £62,500 - £87,500Location: London – HybridContract: PermanentAnnual Leave: 30 Days + Excellent BenefitsClosing Date: 11th July 2025Be Part of the Future of RailThe railway in Britain is undergoing its most signi...
apply.workable.com
and
With the first major iteration to the ITSO Specification in years, the ITSO on Mobile project is enabling the use of mobile credentials across National Rail. This project combines the flexibility of mobile eTickets with the security and speed of NFC technology. You'll be at the forefront of this transformation, designing solutions that bring true walk-up convenience to passengers across the UK.
This role is focused on delivering the technical vision and architecture for RDG’s ITSO on Mobile programme. You'll shape the end-to-end technical architecture of this programme, delivering the UK’s first national mobile smart ticketing solution. You’ll also line-manage our in-house ITSO expert, guiding the blend of transport standards and mobile-first thinking.
Very exciting stuff. Not sure what's wrong with eTickets at the moment aside from the public keys being, err, private. It's already a secure and versatile format. Unless nobody had the foresight to include a cross London field in them... Or to do with scanning speed which I know TfL have issues with but I struggle to see how that can be improved.
ITSO. Where do we start. It just feels like the forgotten fulfilment method confined to PAYG smartcards, season tickets, and the odd Travelcard. They do shine with multi-use products - being harder wearing than paper tickets. Regardless instant/easier loading would be great to have with a mobile version. It's one less thing to carry - at the moment I'm travelling most weekends cross-London with a paper ticket, then I also have SWR and Thameslink smartcards for local PAYG travel either side. Being able to have everything in Google Wallet would be amazing.
Very exciting stuff. Not sure what's wrong with eTickets at the moment aside from the public keys being, err, private. It's already a secure and versatile format. Unless nobody had the foresight to include a cross London field in them... Or to do with scanning speed which I know TfL have issues with but I struggle to see how that can be improved.
Scanning speed is more about the gatelines and how they scan, to be honest (laser vs. camera). They do vary a lot depending on the technology used. I'm sure this will be looked at as part of this but it's more something to look at when doing new gatelines I'd think.
Scanning speed is more about the gatelines and how they scan, to be honest (laser vs. camera). They do vary a lot depending on the technology used. I'm sure this will be looked at as part of this but it's more something to look at when doing new gatelines I'd think.
I do notice how some gatelines can handle a smaller Aztec code on my watch just as quick as a phone then other just can't manage one that small.
Outside of TfL and maybe mainline termini scanning speed doesn't matter as much, of course. I'll use this opportunity to get sidetracked and have a rant again about the fact that Thameslink's gatelines don't accept Advance tickets and some aren't programmed for SWR's Super Off Peaks, which is just a pain and much worse than something being slow to scan. Then TfL complains about barcode scanning speed when they don't properly maintain the magstripe readers or even bother to visually show this by taping them up, which just causes issues.
Rant over. Let's hope it's a positive outcome and not a new version of mTickets
I doubt it will be given that there's specific mention of stuff like eToD - which is good, as it means ToD (ticket on departure) not going away completely but just becoming another method of issuing an e-ticket.
Good news, although I do hope RDG hasn't forgotten that a solution for u-zone tickets as well as cross-London tickets will be needed before they can dispense with CCSTs?
If they think it's only cross-London tickets that are the issue, they may imagine they can get away with only installing barcode readers at the gatelines at the major interchanges, but that would cause problems. U-zone tickets are valid to begin or end the journey at any LU or DLR station within the zones indicated (which could be any of the zones), so that'll be pretty well all gated LU stations that need to accept them if we're not to be left in a materially worse position than we're in now.
Also, LU staff are under longstanding instructions to let people with cross-London tickets finish their cross-London transfer short anywhere along a reasonable route appropriate to the through journey, or anywhere at all in zone 1, although in fairness this does require manual intervention to let the passenger through the gateline, so maybe this could be done by way of a visual inspection, perhaps augmented by a scan with a handheld reader to verify it's a genuine barcode ticket not just an image somebody has knocked up?
== Doublepost prevention - post automatically merged: ==
Scanning speed is more about the gatelines and how they scan, to be honest (laser vs. camera). They do vary a lot depending on the technology used. I'm sure this will be looked at as part of this but it's more something to look at when doing new gatelines I'd think.
It's also partly about where you mount the scanner and how obvious that is to the passenger, and whether the motion required to present the device screen to the scanner will tend to make the device auto-rotate the screen if that setting is enabled. And, of course, you need to allow physical clearance for a variety of different devices of different shapes and sizes to be presented to the scanner (rail ticket barriers are generally okay for this - turnstiles at sports venues, on the other hand....).
I'm sure TfL will be concerned that anything that creates friction and delay, even for a small proportion of passengers, will cause backups which they'll struggle to clear at certain locations at busy times. To that end, hopefully they'll be keen to make sure valid tickets are not rejected. The TOCs have an unfortunate habit of thinking that if a ticket isn't especially common, it's acceptable just to set barriers to reject it and let the person on the gateline sort it out.
Given the (insane to anyone with 5 minutes of security knowledge) close guarding of the spec I can't say anything specific at all. But I will say I see no reason why cross London tickets require any barcode format changes
It's also partly about where you mount the scanner and how obvious that is to the passenger, and whether the motion required to present the device screen to the scanner will tend to make the device auto-rotate the screen if that setting is enabled. And, of course, you need to allow physical clearance for a variety of different devices of different shapes and sizes to be presented to the scanner (rail ticket barriers are generally okay for this - turnstiles at sports venues, on the other hand....).
Whilst not ideal, the positioning is restricted by the need to retrofit them to existing gates, which have all the cabling running through the plinths.
Keeping the scanner away from the card reader also reduces the risk of of an accidental Contactless charge, unlike certain bus ticket machines.
Not keen on barcode scanners slowing down tube gates. Hopefully they'll only be fitted to 1 or 2 barriers to avoid slowing down the vast majority of passengers using contactless/Oyster.
Not keen on barcode scanners slowing down tube gates. Hopefully they'll only be fitted to 1 or 2 barriers to avoid slowing down the vast majority of passengers using contactless/Oyster.
They'd be more likely to slow things down if they were only fitted to a limited number of gates, as people would approach non-equipped gates and faff around for ages trying to scan the Aztec code on the Oyster reader and goodness knows where else, rather than simply scanning the ticket on the actual scanner and getting out of your way.
They'd be more likely to slow things down if they were only fitted to a limited number of gates, as people would approach non-equipped gates and faff around for ages trying to scan the Aztec code on the Oyster reader and goodness knows where else, rather than simply scanning the ticket on the actual scanner and getting out of your way.
I might start keeping records, but in my experience in almost every case of a person causing a delay at a barrier, they are trying to tap through with their phone.
The other big one is paper Travelcards - when last I bought one, the second barrier I put it through ruined it, and I had to be let through manually at every gateline for the remainder of the day. I am a Londoner, I just happen to live in Zone 6 and hold a Network Railcard, so Day Travelcards are often cheaper than PAYG. Day Travelcards bought from LNER are cheaper still if I use my Amex, but LNER's website and App don't issue them to Smartcard, so I have to use a CCST.
Obviously that's also the case if I want to use a through National Rail ticket (another activity that is not the sole prerogative of non-Londoners).
The number of gatelines with gaffer tape over the card slot, or where the card slot looks as though it will work but doesn't, or which reject CCSTs arbitrarily for no obvious reason occasioning a manual check, is quite significant. Switching from them to e-tickets has the potential to be faster rather than slower, if it's done right.
Seems to me this looks like making eTickets on mobile work via NFC so they would work on TfLs (and others) barriers more than traditional "barcode" scanning?
Quite a good solution if it works correctly. You'd just open the ticket on your phone and tap it much like you would with an apple/Google pay card.
As a total bodge job you could actually emulate a "virtual disposable" oyster card on the device - or even a virtual prepaid debit card only allowing transactions against TfLs merchant IDs. This could be topped up with the exact amount required for the journey, and then RDG and TfL would do some back office accounting to sort the right money out (as I assume TfLs split is much less on these cross London tickets than "retail" prices).
Or perhaps another way to do it would be to load your ticket onto a specific payment card. So you link card ending xxxx for your journey and tap through everywhere (assuming the long term plan is to have every station, TfL or not, to have NFC readers and not barcode readers). It wouldn't charge your card for the journey loaded onto your phone?
I very much doubt TfL gate lines would get barcode readers - there's so many of them and a tiny amount of users would use them post contactless. I suspect it is much more likely the other way round that eTickets don't require barcodes to work.
Scanning speed is more about the gatelines and how they scan, to be honest (laser vs. camera). They do vary a lot depending on the technology used. I'm sure this will be looked at as part of this but it's more something to look at when doing new gatelines I'd think.
I've raised this before on here, but I've found scanning speed is more dependant on how often the glass above the scanner is cleaned, Birmingham New Street, for example, is awful, you can see the grime on the glass on some barriers resulting in barcodes not scanning at all.
That reminds me of the 'bodge' of TRIBUTE splitting out CCST 'gate passes' for TfL gates on cross-London journeys, when the main tickets were being issued on the much larger ATB2 stock...
That reminds me of the 'bodge' of TRIBUTE splitting out CCST 'gate passes' for TfL gates on cross-London journeys, when the main tickets were being issued on the much larger ATB2 stock...
It does slightly surprise me that we've not seen a solution along the lines of "scan your e-ticket with cross London validity at this machine and it'll spit out a gate pass", but I guess this plan renders that unnecessary.
Seems to me this looks like making eTickets on mobile work via NFC so they would work on TfLs (and others) barriers more than traditional "barcode" scanning?
Quite a good solution if it works correctly. You'd just open the ticket on your phone and tap it much like you would with an apple/Google pay card.
As a total bodge job you could actually emulate a "virtual disposable" oyster card on the device - or even a virtual prepaid debit card only allowing transactions against TfLs merchant IDs. This could be topped up with the exact amount required for the journey, and then RDG and TfL would do some back office accounting to sort the right money out (as I assume TfLs split is much less on these cross London tickets than "retail" prices).
Or perhaps another way to do it would be to load your ticket onto a specific payment card. So you link card ending xxxx for your journey and tap through everywhere (assuming the long term plan is to have every station, TfL or not, to have NFC readers and not barcode readers). It wouldn't charge your card for the journey loaded onto your phone?
I very much doubt TfL gate lines would get barcode readers - there's so many of them and a tiny amount of users would use them post contactless. I suspect it is much more likely the other way round that eTickets don't require barcodes to work.
What I don't like is it's linked to the device. This sounds like we're not in for etickets but going back to 'orrible M tickets. This must be resisted if this is the case.
Seems to me this looks like making eTickets on mobile work via NFC so they would work on TfLs (and others) barriers more than traditional "barcode" scanning?
Quite a good solution if it works correctly. You'd just open the ticket on your phone and tap it much like you would with an apple/Google pay card.
As a total bodge job you could actually emulate a "virtual disposable" oyster card on the device - or even a virtual prepaid debit card only allowing transactions against TfLs merchant IDs. This could be topped up with the exact amount required for the journey, and then RDG and TfL would do some back office accounting to sort the right money out (as I assume TfLs split is much less on these cross London tickets than "retail" prices).
Or perhaps another way to do it would be to load your ticket onto a specific payment card. So you link card ending xxxx for your journey and tap through everywhere (assuming the long term plan is to have every station, TfL or not, to have NFC readers and not barcode readers). It wouldn't charge your card for the journey loaded onto your phone?
I very much doubt TfL gate lines would get barcode readers - there's so many of them and a tiny amount of users would use them post contactless. I suspect it is much more likely the other way round that eTickets don't require barcodes to work.
All good ideas, but looking again at the job adverts, it is only the barcode one that says anything about making it work for cross-London travel on TfL services.
The ITSO one gives the scope as "across National Rail".
I'm never sure if cross-London tickets, if you could find one that was set up for ITSO fulfillment, would work on TfL barriers currently? I've never felt like risking it as TfL gateline staff would almost always be ill-equipped to examine a ticket held on a Smartcard if the barrier rejected it. I know Travelcards held on ITSO work fine on tube barriers. As I understand the job advert it's purely to do away with the need to issue the cards to people, by requisitioning the passenger's phone.
As I say, my prediction is they'll only put barcode scanners on the gatelines at the stations where TfL is worried manual checks would be impractical and would cause delays or a crush. So just the tube gatelines at the main London terminals (and probably only on the ones handling the main flow of passengers transferring to and from National Rail, not necessarily all entrances and exits). Consequently anyone wanting to use a U-zone ticket or make a cross-London transfer interchanging at a smaller, gated station (e.g. West Hampstead) will have to stick with CCST until they're withdrawn if we want smooth passage through the ticket barrier, because after that it will be a case of asking to be let through and hoping the gateline staff remember their training...
It shouldn't make any difference at all. Itso mobile has already been tested for the UK and can achieve the same response time as a plastic Itso ticket, which is already in common usage across all tfl modes.
It shouldn't make any difference at all. Itso mobile has already been tested for the UK and can achieve the same response time as a plastic Itso ticket, which is already in common usage across all tfl modes.
To be fair while the response time would be the same the fiddling with the phone to pull up the correct Wallet pass would cause at least some gateline obstruction, though possibly less than scanning barcodes so it would make sense to encourage this form of fulfilment.
It's fairly common to have NFC passes on phones now - Ticketmaster do it - and Nando's do for their loyalty scheme, so we must be near the point that NFC scanners are cheaper than barcode scanners!
To be fair while the response time would be the same the fiddling with the phone to pull up the correct Wallet pass would cause at least some gateline obstruction, though possibly less than scanning barcodes so it would make sense to encourage this form of fulfilment.
Only if they don't set up a default "transit mode" card or whatever it's called; once you've done that you simply tap the phone with no need to interact with it in any way, unlike an NFC pass. In my observation most users in London now do have this set up, which means they simply tap their phone blind without really breaking step - back to the early days of Oyster when you'd just tap your whole wallet as there'd only be one such card in it, but with a phone.
Exactly the same as contactless was when it first started? Yes, and it was grossly annoying when gates started to stack up because people didn't know how to use their phone properly.
Only if they don't set up a default "transit mode" card or whatever it's called; once you've done that you simply tap the phone with no need to interact with it in any way, unlike an NFC pass. In my observation most users in London now do have this set up, which means they simply tap their phone blind without really breaking step - back to the early days of Oyster when you'd just tap your whole wallet as there'd only be one such card in it, but with a phone.
Exactly the same as contactless was when it first started? Yes, and it was grossly annoying when gates started to stack up because people didn't know how to use their phone properly.
I can't see people being willing to do that when they also wish to use their phone to make contactless payments. That sounds like classic SNCF "we are the only ones who matter" arrogance to me.
Exactly the same as contactless was when it first started? Yes, and it was grossly annoying when gates started to stack up because people didn't know how to use their phone properly.
My device hasn't once ever done this so I can only assume it's primarily an Apple thing. It is incompetent but also it's really Apple's fault for popularising and sustaining security theatre.
My device hasn't once ever done this so I can only assume it's primarily an Apple thing. It is incompetent but also it's really Apple's fault for popularising and sustaining security theatre.
If your phone doesn't have any kind of active security when using contactless for general payments, then TBH I wouldn't want that. I like the way Apple Pay is much more secure than even a physical card. I've knocked the contactless limit on my physical card right down (I think it was a tenner but I'd have to check) as I hugely prefer that security.
It is not "security theatre", it's a step-change with contactless that removes its security downsides pretty much entirely.
Selecting a transit card removes this for the very low value transactions that TfL carry out, but doesn't leave it vulnerable to other things.
It was an issue in the early days of contactless, and it'd be an issue again with NFC passes because you have to, on all phones, select it before presenting it unless it is the only contactless payment method on the phone.
I can't see people being willing to do that when they also wish to use their phone to make contactless payments. That sounds like classic SNCF "we are the only ones who matter" arrogance to me.
I am pretty sure it doesn't affect your Google Wallet at all. The Lignes d'Azure app presumably has an up to date list of every terminal and only activates on those. I don't know precisely but I definitely used Google Pay in Nice during the validity of my tram single.
== Doublepost prevention - post automatically merged: ==
If your phone doesn't have any kind of active security when using contactless for general payments, then TBH I wouldn't want that. I like the way Apple Pay is much more secure than even a physical card. I've knocked the contactless limit on my physical card right down (I think it was a tenner but I'd have to check) as I hugely prefer that security.
You've misunderstood how Google Pay works, then. It's not insecure, nor can it sensibly be described as any less secure than Apple Pay. Both are miles better than physical cards anyway.
== Doublepost prevention - post automatically merged: ==
We are aware of an issue with emails from the Forum to Microsoft-based email accounts (hotmail/outlook/live.com email addresses). This is being looked into currently, thanks for your patience meanwhile.
apply.workable.com
