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!
I read that as the King's Cross gateline would let you in correctly, but the tap wouldn't register in the GTR backoffice. In that case, as King's Cross let the passenger through there should still be a transient ticket and tap record on the card from King's Cross, as that's all offline.
The standalone reader should then know it's a tap out from the data on the card, and therefore the backoffice should know that it's the tap in not the tap out that's missing, unless I've missed something (entirely possible!)
I don’t know any details about how the cards and touches work but there shouldn’t ever be a situation where touch ins don’t get recorded, touch ins are recorded as touch outs and touch outs get recorded as touch ins.
All of the above have happened to me, at gatelines a as well as standalone validators. I get the complication about standalone validators and the direction of travel, I also get that barriers need to be set up correctly by staff but none of these ever seem to be an issue with Oyster or contactless - only KeyGo.
I’ve reported this all to GTR in the past and assured it had been fixed but it hasn’t. I’ve given up on KeyGo for now and will continue to use traditional tickets.
I read that as the King's Cross gateline would let you in correctly, but the tap wouldn't register in the GTR backoffice. In that case, as King's Cross let the passenger through there should still be a transient ticket and tap record on the card from King's Cross, as that's all offline.
The standalone reader should then know it's a tap out from the data on the card, and therefore the backoffice should know that it's the tap in not the tap out that's missing, unless I've missed something (entirely possible!)
I see what you mean but I think it only works in collecting the taps from devices. I really don't know what information is held on the card during a journey.
That's very poor, because even when the backoffice is failing to get the taps, it should be able to infer the direction based on the transient ticket on the card when you tap the standalone reader
Does the transient ticket data actually go to backoffice though (or get read by the standalone readers)? I thought it didn't.
I'm under the impression that standalone readers simply get registered as "touch" while barriered touches are marked with the appropriate "in"/"out" flag as per their configuration by Cubic. The transient ticket data may be updated correctly, but I think the actual data sent back to GTR is simply the record of a tap.
== Doublepost prevention - post automatically merged: ==
I don’t know any details about how the cards and touches work but there shouldn’t ever be a situation where touch ins don’t get recorded, touch ins are recorded as touch outs and touch outs get recorded as touch ins.
Sadly, that's not the case in reality. I've had it at Gatwick when the concourse redevelopment works were being completed -- standalone reader touch was counted as a tap in for my commute when I had touched in previously at my home station.
== Doublepost prevention - post automatically merged: ==
FYI, if anyone cares, the keyGo journey data is actually available for the last 365 days rather than the 8 weeks GTR provides on their site.
You can manually perform the web requests to their API for the last 365 days, provided the date range is >=62 days.
I've just found journeys from Sept 2022! The data might be of some interest.
You can piece together how the backend calculates the "best fare" via the reasonCode attribute for each object under tickets. Some of mine are, as above, "NO_SAVING", while others are "CHEAPER_THAN_SINGLES" for a return ticket covering multiple legs and "COVERED_BY_PREPAID" for a manually loaded ticket that covers the journey/legs.
The reason that same-station-exits are highlighted red (I think they were when I last used keyGo?) is that they are marked with reasonCode "INCOMPLETE".
In my experience it obviously doesn't, but makes an estimate based on one's recent travels - e.g. I had gone from St Albans to St Pancras when the trains were stopping in the upper platforms where KeyGo doesn't reliably work, so I just had the St Albans taps. They gave me a return to Bedford, I assume as that was where my most recent journeys had been to [I corrected it on their website, even though the Bedford journey would have been marginally cheaper].
They don't "recommend not using it"... You can't use it — it's only valid on GTR services.
You can make the decision as to whether it's flexible enough for you. It's perfect for my sporadic trips as GTR are the only people that serve my station!
As there are a number of these PAYG systems feeding into London, it would be useful if they could all support any other London and SE PAYG cards. Perhaps they can? I did look at the variously colour-coded map published by SWR and it seemed to allow travels into GWR territory, but it didn't look as if the SWR system would support trips onto GTR. Chris Green would have had it sorted!
SWR does allow travel on Southern between Dorking and Victoria (and maybe some others I don't remember off the top of my head), but there aren't many other co-acceptance schemes unfortunately.
As there are a number of these PAYG systems feeding into London, it would be useful if they could all support any other London and SE PAYG cards. Perhaps they can? I did look at the variously colour-coded map published by SWR and it seemed to allow travels into GWR territory, but it didn't look as if the SWR system would support trips onto GTR. Chris Green would have had it sorted!
I use Keygo quite extensively south of and up to London without the issues others report. One of my bugbears it that even on GTR services it doesn't go all the way along the coastway years after we were told that this would be coming soon. I think the issue is the apportionment of revenue between the TOCs when there are multiple routes for the purpose of fares. Portsmouth to Victoria for instance would be presumably charged at the route Three Bridges fare and be allocated to GTR but there's no way the system could tell if you took SWT to Clapham Junction and then Southern to Victoria.
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.
The data might be of some interest.
