Like many others, I have used LNER to buy tickets during the current 10% back offer. One of the tickets I bought was from London Thameslink to Brighton. I specifically searched for London Thameslink as the journey origin, and double checked that it was showing as the fare origin when buying the ticket. The suggested journeys were to and from London Bridge, because that's the closest station to Brighton.
I chose eTicket as my fulfulfilment method. The PDF version is fine:
However when downloading the Google Wallet version, I noticed a discrepancy. The 'pass' itself states that the ticket is from London Bridge and gives LBG as the origin code:
This is not correct. The fare has been issued from London Thameslink, and the origin code should accordingly be THK. I scanned the Aztec code and the data does show that the ticket is from THK - so it would appear this is simply an issue with the origin data that LNER are including in the Google Wallet data, not the actual encoding of the barcode. There seems to be an incorrect assumption that the fare origin/destination will be the same as the (suggested) journey's origin/destination.
As it happens I probably will be travelling out from London Bridge, but on my return journey I may get off at Farringdon, which doesn't have barcode scanners. I wouldn't want to encounter problems with the barrier staff if they think I've overtravelled. Of course, I could use the PDF - but that negates the convenience of being issued a Google Wallet pass (e.g. that a notification shows up automatically around the time of your selected trains, meaning you don't need to fumble to find the PDF).
Hopefully someone from LNER can pick this up and fix it... I figured that posting here is more likely to get a response from someone who understands the problem.
I chose eTicket as my fulfulfilment method. The PDF version is fine:
However when downloading the Google Wallet version, I noticed a discrepancy. The 'pass' itself states that the ticket is from London Bridge and gives LBG as the origin code:
This is not correct. The fare has been issued from London Thameslink, and the origin code should accordingly be THK. I scanned the Aztec code and the data does show that the ticket is from THK - so it would appear this is simply an issue with the origin data that LNER are including in the Google Wallet data, not the actual encoding of the barcode. There seems to be an incorrect assumption that the fare origin/destination will be the same as the (suggested) journey's origin/destination.
As it happens I probably will be travelling out from London Bridge, but on my return journey I may get off at Farringdon, which doesn't have barcode scanners. I wouldn't want to encounter problems with the barrier staff if they think I've overtravelled. Of course, I could use the PDF - but that negates the convenience of being issued a Google Wallet pass (e.g. that a notification shows up automatically around the time of your selected trains, meaning you don't need to fumble to find the PDF).
Hopefully someone from LNER can pick this up and fix it... I figured that posting here is more likely to get a response from someone who understands the problem.
