How smart are gateline e-ticket readers?

[Doctor Fegg]

Let's say I've found an Interesting Ticket™ which has less stringent peak restrictions at a London Terminal than most others of that ticket type.

I'm pretty sure that if I had a standard orange credit-card sized ticket, the gateline readers would object based just on the ticket type, and similarly, the gateline staff would take one look at the ticket type and not let me through. After an hour of arguing, producing itineraries, looking up restriction codes and so on, I might be allowed on.

But if I have an e-ticket and scan it, is the gateline smart enough to know that the ticket is technically permitted? Or does it just think "uhuh, Super Off-Peak at 6pm" like the magstripe readers and refuse?

 

[fandroid]

I suspect that the gatelines are no more sophisticated with etickets than they are with magstripe. And I don't know how you'd test that without risking the aforementioned "hour of arguing".

Having said that I'm reasonably sure that I've travelled on super-offpeak returns for long distance journeys northwards via London and been OK returning within the restriction times applicable to super-offpeak and Evening Out when passing through Waterloo going southwards. Those would have been magstripe tickets too, for transfer on the Tube

 

[James H]

I seem to recall previous threads suggested that in many cases the logic applied to eTickets is actually less sophisticated than that used for CCST

 

[XCTurbostar]

I seem to recall previous threads suggested that in many cases the logic applied to eTickets is actually less sophisticated than that used for CCST

I believe this is the case too, there are some which will just check that the eTicket is valid full stop and not check for any restrictions.

 

[Tazi Hupefi]

It depends on both the ticket barrier type and the TOC.

The analysis of e-tickets is becoming an increasingly back-end/retrospective exercise, naturally, as you then have the full/more complete journey information available. However, some gates are getting smarter too - e.g. some Advance tickets can be rejected if it's far too early for entry to a station for a specific departure.

There's also a few new bits of supplemental gateline kit floating around the network with various trials - often with plain clothes managers/RPOs remotely observing data in realtime.

Without sharing the tickets, what sort of route would you expect to take?

 

[Joshua_Harman]

I seem to recall previous threads suggested that in many cases the logic applied to eTickets is actually less sophisticated than that used for CCST

I’ve also found the same for ITSO Fares, certain ticket types I’ve held have been rejected As a paper ticket at certain stations but a tap of the smarty card loaded with the same ticket opens the gate no fuss,

 

[island]

I’ve also found the same for ITSO Fares, certain ticket types I’ve held have been rejected As a paper ticket at certain stations but a tap of the smarty card loaded with the same ticket opens the gate no fuss,

And I’ve had the opposite, with paper tickets being accepted and the same ticket on smartcard refused by the gateline.

 

[Doctor Fegg]

It depends on both the ticket barrier type and the TOC.

The analysis of e-tickets is becoming an increasingly back-end/retrospective exercise, naturally, as you then have the full/more complete journey information available. However, some gates are getting smarter too - e.g. some Advance tickets can be rejected if it's far too early for entry to a station for a specific departure.

Without sharing the tickets, what sort of route would you expect to take?

Effectively it's an off-peak return ticket for L&SE station A -> London terminal -> cross-London transfer -> London terminal -> L&SE station B. One of the terminal<->L&SE legs has less stringent peak restrictions than is usual for that type of ticket. It's reasonably clearly human error when the fare was set up.

 

[Hadders]

Tickets involving cross London transfers are not supposed to be fulfilled to e-tickets.

 

[Tazi Hupefi]

Effectively it's a return ticket for L&SE station A -> London terminal -> cross-London transfer -> London terminal -> L&SE station B. One of the terminal<->L&SE legs has less stringent peak restrictions than is usual for that type of ticket. It's reasonably clearly human error when the fare was set up.

For starters, TfL will refuse you access to their infrastructure, but if it's an anomalous route etc, there will always be compromises to be made as I'm sure you will appreciate. That cross London transfer just isn't going to happen unless you walk / use another ticket or start at the central London terminal.

Can you say what the restriction code is without telling us the origin/destination please - it shouldn't reveal anything of use.

 

[Doctor Fegg]

Tickets involving cross London transfers are not supposed to be fulfilled to e-tickets.

Absolutely yes, I'm aware that's the elephant in the room. OTOH I know there are people who have successfully persuaded various sites/apps to do it, and given that this fare also has a plausible non-London routing, I suspect it would be possible in this case. But I'm not going to attempt that if the gateline won't like it anyway!

For starters, TfL will refuse you access to their infrastructure, but if it's an anomalous route etc, there will always be compromises to be made as I'm sure you will appreciate. That cross London transfer just isn't going to happen unless you walk / use another ticket or start at the central London terminal.

Can you say what the restriction code is without telling us the origin/destination please - it shouldn't reveal anything of use.

In this case posting the restriction code would narrow it down enough that a canny pricing manager would find it pretty quickly, I fear, but I'm happy to let you know via PM if you drop me a line.

 

[Haywain]

Let's say I've found an Interesting Ticket™ which has less stringent peak restrictions at a London Terminal than most others of that ticket type.

I'm pretty sure that if I had a standard orange credit-card sized ticket, the gateline readers would object based just on the ticket type, and similarly, the gateline staff would take one look at the ticket type and not let me through. After an hour of arguing, producing itineraries, looking up restriction codes and so on, I might be allowed on.

But if I have an e-ticket and scan it, is the gateline smart enough to know that the ticket is technically permitted? Or does it just think "uhuh, Super Off-Peak at 6pm" like the magstripe readers and refuse?

Ultimately, there is only one way you will find out.

 

[RJ]

Can you say what the restriction code is without telling us the origin/destination please - it shouldn't reveal anything of use.

I wouldn’t advise that - someone like me will take the information given so far and work out what that ticket likely is within a minute. If I can do that, so can the people who have a vested interest in correcting anomalies.

I’d also avoid getting tickets like this issued as e-tickets. The less of a paper trail is left using unintentionally good value fares, the better.

 

[Tazi Hupefi]

To be fair, it wouldn't take long without any information at all.

You'd only need to run a quick LENNON query where the Cross London flag is set and the fulfilment method is e-ticket to generate a list of problematic tickets.

I'd definitely recommend fulfilling to a paper ticket.

 

[ChrisC]

I wouldn’t advise that - someone like me will take the information given so far and work out what that ticket likely is within a minute. If I can do that, so can the people who have a vested interest in correcting anomalies.

I’d also avoid getting tickets like this issued as e-tickets. The less of a paper trail is left using unintentionally good value fares, the better.

An interesting point. There‘s a ticket that I have used occasionally over the years and only ever buy it as a paper ticket from the TVM. I would never buy it from a booking office or on the train where I would have to stipulate the routing. I have actually always avoided buying it online and collecting it from the TVM. I’d therefore not thought about the implications of buying it as an e-ticket.

 

[sor]

And I’ve had the opposite, with paper tickets being accepted and the same ticket on smartcard refused by the gateline.

me too. My most recent trip involved an off peak which I put on ITSO. Bought at machine, walked over to gate - rejected. Gate person scanned it with his phone app, had no idea why it was rejected, let me through. I've bought other off peaks (different destinations, same TOC, machines and origin) and those worked fine

Didn't try it on the way back as all gates were open anyway.

 

[CyrusWuff]

The implementation of walk-up tickets on ITSO as it currently stands is...not great. though it's better than barcode tickets!

Irritatingly, the standard does allow for the ticket type and actual restriction code to be included, but I don't believe anyone's using that functionality at present. (Or whether Ticket Issuing Systems or validation equipment would support it were a TOC to enable it.)

 

[RailAleFan]

A gateline should be able to validate a ticket using the same Journey Planner API that issued it.

 

[Wallsendmag]

All depends which brand of gates you are using. Some are much better at handling barcoded tickets than others.

 

[OscarH]

The implementation of walk-up tickets on ITSO as it currently stands is...not great. though it's better than barcode tickets!

Irritatingly, the standard does allow for the ticket type and actual restriction code to be included, but I don't believe anyone's using that functionality at present.

How is ITSO implemented better than barcodes if no one is even bothering to encode the ticket type and restrictions code?

 

[infobleep]

I wouldn’t advise that - someone like me will take the information given so far and work out what that ticket likely is within a minute. If I can do that, so can the people who have a vested interest in correcting anomalies.

I’d also avoid getting tickets like this issued as e-tickets. The less of a paper trail is left using unintentionally good value fares, the better.

In the past, I have been slightly weary of eTickets and some on here have said it's no different from getting a paper ticket and it is the ticket, not the medium, that matters. They have said checking tickets would be no different from a paper ticket.

Yet here you mention not leaving a paper trail, which points to paper tickets being better.

 

[CyrusWuff]

How is ITSO implemented better than barcodes if no one is even bothering to encode the ticket type and restrictions code?

My understanding is that ITSO validation is broadly in line with the principles for magstripe validation, but barcode validation is less detailed.

 

[yorkie]

I suspect that the gatelines are no more sophisticated with etickets than they are with magstripe. ....

There correct. And it's up to the TVM supplier to program the gates correctly. In all likelihood, the TVM supplier will be enlisting the assistance of the company who provides their fares data.

It's probably impossible to always reject every possible invalid ticket and accept every possible valid ticket; in any case there is some element of subjectivity, for example if a ticket is valid for arrivals into London from 1000, then given timetables can change and given you need to allow some time for people to pass through a barrier in order to catch their train without rushing, some leeway has to be provided.

In terms of routeing that's less subjective but some routeing permissions are debatable in some cases.

It's actually quite a complicated subject in its own right

 

[Wallsendmag]

A gateline should be able to validate a ticket using the same Journey Planner API that issued it.

 

[Doctor Fegg]

Thanks for all the answers.

I think the consensus is that an e-ticket doesn’t guarantee (at least) that the interesting validity will be accepted by the gates, and in fact it probably won’t.

Given that the gateline staff in question have some notoriety for disputing valid tickets in the evening peak, I think this is one of those loopholes that’s going to remain unexploited, by me at least. Shame though - it would be a worthwhile saving!

 

[Russel]

I seem to recall previous threads suggested that in many cases the logic applied to eTickets is actually less sophisticated than that used for CCST

In my personal experience, this has been the case, when using paper tickets and doing a break of journey, no end of barrier would reject them, yet with e tickets that no longer seems to happen anywhere near as often.

 

[Adam Williams]

Wasn't that the whole point of the TTK T-Vals? (Some of) the gatelines were too useless?

 

[Haywain]

In my personal experience, this has been the case, when using paper tickets and doing a break of journey, no end of barrier would reject them, yet with e tickets that no longer seems to happen anywhere near as often.

Is that less sophisticated or more?

Wasn't that the whole point of the TTK T-Vals? (Some of) the gatelines were too useless?

They are more about the fact that you can't reject certain tickets on eTicket as you can on CCST.

 

[Adam Williams]

Sure sounds to me like a useless gateline if it can't do anything with the discount status code in the barcode payload

I can't say I've ever worked on a gateline but being able to do a revenue block and check for people's railcards / discount entitlements sounds like a fairly fundamental requirement for revenue protection.

I assume the LNER S&B gates can do it?

 

[Tazi Hupefi]

Sure sounds to me like a useless gateline if it can't do anything with the discount status code in the barcode payload

I can't say I've ever worked on a gateline but being able to do a revenue block and check for people's railcards / discount entitlements sounds like a fairly fundamental requirement for revenue protection.

One of the issues was that certain parts of the industry were against the introduction of smart ticketing and did the bare minimum in terms of cost/funding to achieve compliance.

The other development that the industry is slowly digesting is that smart ticketing is moving a lot of the revenue protection activity to the back office and data based. Less conflict, violence and interruptions to the customer experience than sending heavies through a carriage or blocking an exit, especially when the vast majority of journeys are completely fine.

Some operators are training their revenue protection teams in more detailed data led investigation procedures, third party data requests, fraud legislation etc, to complement and further their front line duties.

Concepts such as "gateless gatelines" etc are also on the horizon.