GWR Contactless Readers Can See Whether Tapped?

[dasfvzcx]

Today I was travelling from Reading to London Paddington on GWR.

The ticket inspector came, and I said I had used Contactless. He said he had a device for that, but needed to boot it up. It looked like an iPhone in a yellow case.

They then went on, and did not return (well, they did, but walked past), I think as the train was running early.

On interesting point they mentioned is that they had found when checking that often people had not tapped in.

This confused me because I thought that was fundamentally impossible at this point in time? I thought the only thing they could check is (a) whether your card is comptatible (does it tap) and (b) whether your card has been blacklisted, due to the way the taps are centrally collected.

 

[duffield]

...
I thought the only thing they could check is (a) whether your card is comptatible (does it tap) and (b) whether your card has been blacklisted, due to the way the taps are centrally collected.

That's certainly been repeated here concerning TfL. However, in theory there's probably nothing to stop GWR setting up their systems and devices to receive updated tapped in card lists via mobile data at the start and during the journey. It would be interesting to know if they actually do this. Probably easier for GWR to do than TfL due to not being in a load of tunnels. And they could just fall back to the blacklist method if updates are not coming through.

 

[dasfvzcx]

That's certainly been repeated here concerning TfL. However, in theory there's probably nothing to stop GWR setting up their systems and devices to receive updated tapped in card lists via mobile data at the start and during the journey. It would be interesting to know if they actually do this. Probably easier for GWR to do than TfL due to not being in a load of tunnels. And they could just fall back to the blacklist method if updates are not coming through.

Theres a lot of moving parts though in that case, and e.g. if the gate loses connection (I saw some stuff about TfW), or also if it's not a GWR gate (does GWR control all stations/gates all trains on this line go to)?

My feeling would be that it is simply the blacklist, unless someone has some scoop of GWR doing quite a bit of heavy lifting (and potential problems?)?

 

[officewalla]

So what people are saying is that without a means of checking if the card has indeed been tapped in, it is very easy to avoid a fare if and until you need to tap out of a gate at the other end.

 

[Watershed]

So what people are saying is that without a means of checking if the card has indeed been tapped in, it is very easy to avoid a fare if and until you need to tap out of a gate at the other end.

The majority of journeys within the contactless PAYG area of validity involve passing through at least one set of barriers. So at best, you are going to be charged one or two maximum fares for an incomplete journey, and at worst your card will be blocked after the second failed revenue inspection (i.e. where you were not touched in at the time of the inspection). You are also charged a maximum fare if you have a failed inspection, I believe.

== Doublepost prevention - post automatically merged: 28 May 2025 ==

Theres a lot of moving parts though in that case, and e.g. if the gate loses connection (I saw some stuff about TfW), or also if it's not a GWR gate (does GWR control all stations/gates all trains on this line go to)?

My feeling would be that it is simply the blacklist, unless someone has some scoop of GWR doing quite a bit of heavy lifting (and potential problems?)?

The tap data take time to propagate their way from the barrier/validator to TfL's backend system, and would take longer still to make their way to the contactless inspection devices.

Since you could be inspected just after tapping in and getting on the train, I don't think this can ever be a realistic solution and the suggestion that they can see if people haven't touched in can't be true.

 

[dasfvzcx]

The tap data take time to propagate their way from the barrier/validator to TfL's backend system, and would take longer still to make their way to the contactless inspection devices.

Since you could be inspected just after tapping in and getting on the train, I don't think this can ever be a realistic solution and the suggestion that they can see if people haven't touched in can't be true.

This was my thinking, and I think it is unlikely GWR can tap into this before it goes to TfL?

I think the only way this could work, is presumably similar to Oyster, where the card "knows" it has been tapped in or not, but I am not sure this is feasible with payment cards as I know little about how they work technically?

The majority of journeys within the contactless PAYG area of validity involve passing through at least one set of barriers. So at best, you are going to be charged one or two maximum fares for an incomplete journey, and at worst your card will be blocked after the second failed revenue inspection (i.e. where you were not touched in at the time of the inspection). You are also charged a maximum fare if you have a failed inspection, I believe.

Until now, GWR was quite easy to game if one wanted, though not consistently. I am sure most are aware of the ungated platforms at Paddington, secondly there are certain times one can be relatively certain the barriers will be open in Reading (sometimes at weird times, I assume might be when staffing changes? I.e. where the barriers go closed -> open for ~30-45min -> closed consistently), so one could previously game the system relatively safely I reckon.

I don't, but I like to game these things out. I guess these GWR devices, even if only blacklist/maximum fare/adding black marks to cards -> blacklist are an improvement, though the blacklist only really works for those with few cards/who are not aware of it.

The maximum fare also doesn't always work, especially of one took Elizabeth Line all the way from the core to Reading, the maximum fare would be less than the total fare (I am sure this is something many are aware of and I think TfL would be already), so not tapping out (if barriers are open) is cheaper.

 

[swt_passenger]

This was my thinking, and I think it is unlikely GWR can tap into this before it goes to TfL?

I think the only way this could work, is presumably similar to Oyster, where the card "knows" it has been tapped in or not, but I am not sure this is feasible with payment cards as I know little about how they work technically?

I believe from previous discussions it’s not possible, ie nothing is ever written back to contactless bank cards.

 

[Horizon22]

GTR have similar devices. You can see certain information on them as to when the card was last used. This applies to both Oyster & Contactless as well as smartcards.

 

[kevjs]

The tap data take time to propagate their way from the barrier/validator to TfL's backend system, and would take longer still to make their way to the contactless inspection devices.

How much longer though? We've reached a point where tapping to pay* often results in multiple notifications (Curve, Barclays, and Google Pay in my case) appearing on a smart watch before the payment terminal shows approved. In my case using a Curve card on Google Pay that means something like Payment Terminal -> Terminal Provider -> Curve -> Barclays -> Curve -> Google -> Terminal Provider -> Google/Curve/Barclays Apps all happening within a second or two.

Shouldn't be outside the relmes of possibility to have it reaching a checking device within 5 minutes or so (in areas with a signal) - if it's something that needs docking to sync then the dock could have a better antenna than a phone & be setup to use WiFi at stations - and have it operate in different modes (i.e. realtime/blacklist mode) depending on if it's synced before or since the last station, potentially playing it safe (e.g. you get the benefit of the doubt once, but post journey reconsiliation would put a mark against the card if it hadn't tapped in, and if it happens again then it presumes non payment).

Even the slowest ADSL connection would be way more than enough to sync the tap on/off data from a rural station.

* including the 10p Nottingham Contactless or TfL take at the start of the first journey of the day and refund about a week after taking the settled amount.

 

[Watershed]

How much longer though? We've reached a point where tapping to pay* often results in multiple notifications (Curve, Barclays, and Google Pay in my case) appearing on a smart watch before the payment terminal shows approved. In my case using a Curve card on Google Pay that means something like Payment Terminal -> Terminal Provider -> Curve -> Barclays -> Curve -> Google -> Terminal Provider -> Google/Curve/Barclays Apps all happening within a second or two.

Shouldn't be outside the relmes of possibility to have it reaching a checking device within 5 minutes or so (in areas with a signal) - if it's something that needs docking to sync then the dock could have a better antenna than a phone & be setup to use WiFi at stations - and have it operate in different modes (i.e. realtime/blacklist mode) depending on if it's synced before or since the last station, potentially playing it safe (e.g. you get the benefit of the doubt once, but post journey reconsiliation would put a mark against the card if it hadn't tapped in, and if it happens again then it presumes non payment).

Even the slowest ADSL connection would be way more than enough to sync the tap on/off data from a rural station.

* including the 10p Nottingham Contactless or TfL take at the start of the first journey of the day and refund about a week after taking the settled amount.

TfL contactless PAYG is a separate mode of payment from regular contactless transactions though. The barriers don't instantly synchronise with the backend each time a card is touched in or out - that would cause too much delay in opening the barriers. Some metro systems abroad work like that, but they are generally quieter ones where contactless isn't as prevalent.

Instead the transaction data are batched together and sent roughly every 5 or 10 minutes - you can see this from the TfL Go app, which displays the latest data the backend system has. However, like any data link these reconciliations sometimes fail and so you can end up with touches taking hours or even until the next day to appear in the TfL system. It's not a rare occurrence either, I have seen it happen on my own journeys a couple of times just in the last year for example.

That's why you couldn't enforce 'being touched in' when undertaking onboard checks. There simply isn't enough certainty in the data to be able to do so.

 

[norbitonflyer]

This was my thinking, and I think it is unlikely GWR can tap into this before it goes to TfL?

I think the only way this could work, is presumably similar to Oyster, where the card "knows" it has been tapped in or not, but I am not sure this is feasible with payment cards as I know little about how they work technically?

Until now, GWR was quite easy to game if one wanted, though not consistently. I am sure most are aware of the ungated platforms at Paddington, secondly there are certain times one can be relatively certain the barriers will be open in Reading (sometimes at weird times, I assume might be when staffing changes?

I was surprised when visiting the GWS centre at Didcot yesterday that the only access and egress is through the station subway and the station staff just let you through the barriers if you say that's where you're going/have been. (At least during times when the centre is open!)
No prebooking required,' for visiting the centre, so they can't insist on proof that's where you're going

 

[RGM654]

I was surprised when visiting the GWS centre at Didcot yesterday that the only access and egress is through the station subway and the station staff just let you through the barriers if you say that's where you're going/have been. (At least during times when the centre is open!)
No prebooking required,' for visiting the centre, so they can't insist on proof that's where you're going

Conversely(?) if you travel to Didcot by train to visit the Centre you have no need to pass the barriers when you arrive or when you leave, so no need to present your ticket.

 

[LittleRedTrain]

The arrangements with Didcot Railway Centre have been in place for decades, probably before automatic barriers were even a thing. Whether GWR would a similar new arrangement these days is debatable, but given the centre's limited opening days and times, I suspect it's not exactly a big loophole for fare dodgers.
I'd imagine places like Twyford and Tilehurst are much 'leakier'. I suspect barriering Reading West will have made much more of an impact on fare dodging in the area.

 

[mrmartin]

TfL contactless PAYG is a separate mode of payment from regular contactless transactions though. The barriers don't instantly synchronise with the backend each time a card is touched in or out - that would cause too much delay in opening the barriers. Some metro systems abroad work like that, but they are generally quieter ones where contactless isn't as prevalent.

Instead the transaction data are batched together and sent roughly every 5 or 10 minutes - you can see this from the TfL Go app, which displays the latest data the backend system has. However, like any data link these reconciliations sometimes fail and so you can end up with touches taking hours or even until the next day to appear in the TfL system. It's not a rare occurrence either, I have seen it happen on my own journeys a couple of times just in the last year for example.

That's why you couldn't enforce 'being touched in' when undertaking onboard checks. There simply isn't enough certainty in the data to be able to do so.

?? It really wouldn't cause a delay. It's very possible to communicate with a remote (London based) server in less than 10ms to send tap data.

Regardless though, they should be sending data in real time where possible - not batching it, or if they really need to batch it, send it every 10s or so. The data will be tiny (a handful of bytes) and it has key revenue enforcement implications. If it takes 10 minutes for the system to update it means that revenue enforcement people walking through trains don't know what's really going on.

 

[Watershed]

?? It really wouldn't cause a delay. It's very possible to communicate with a remote (London based) server in less than 10ms to send tap data.

Think about how long it takes for a contactless payment to go through. You are typically looking at at least 0.5s if not 1 or 2 seconds. Multiply that by the number of people using each barrier and you can see the problem.

Regardless though, they should be sending data in real time where possible - not batching it, or if they really need to batch it, send it every 10s or so. The data will be tiny (a handful of bytes) and it has key revenue enforcement implications. If it takes 10 minutes for the system to update it means that revenue enforcement people walking through trains don't know what's really going on.

Arguably yes, but evidently it hasn't been seen as necessary to invest in upgrading the system to have this capability. Most people don't know about this 'loophole' in the system (which has many restrictions and isn't feasible to make use of on a regular basis).

More to the point, even with real-time data, how could you be sure that someone definitely didn't touch in, given the possibility of communication delays or data link outages (which are surprisingly common)? It's not reasonable to apply penalties first and ask questions later. We have seen how ready the TOCs are to penalise people, and how hard it is to get their Prosecutions departments to actually take a proper look at the evidence when this happens.

 

[mrmartin]

Think about how long it takes for a contactless payment to go through. You are typically looking at at least 0.5s if not 1 or 2 seconds. Multiply that by the number of people using each barrier and you can see the problem.

That's different to sending the tap data in real time though? Anyway, many banks would process very quickly. You could just set a timeout of 0.25s or something and open the gates anyway (at busy times - off peak it could wait longer)? Many banks will respond very quickly, some are slower than others. Keep in mind a pub/shop contactless terminal is not optimised for speed really - typically using 4G and needs to set up a connection to the payment processor. TfL could set it up very differently and I am sure that with not a huge amount of effort you could do online authorisations very quickly.

 

[Starmill]

That's different to sending the tap data in real time though? Anyway, many banks would process very quickly. You could just set a timeout of 0.25s or something and open the gates anyway (at busy times - off peak it could wait longer)? Many banks will respond very quickly, some are slower than others. Keep in mind a pub/shop contactless terminal is not optimised for speed really - typically using 4G and needs to set up a connection to the payment processor. TfL could set it up very differently and I am sure that with not a huge amount of effort you could do online authorisations very quickly.

They already do them quite quickly in my experience. What of it? Judging by the number of cases I've had over the years where one of my taps is "lost" and then regularises again about 5 days later it's hardly an unusual occurrence.

If you intend to charge a customer a Penalty Fare you need to be 99.99% sure in every case.

== Doublepost prevention - post automatically merged: 31 May 2025 ==

If it takes 10 minutes for the system to update it means that revenue enforcement people walking through trains don't know what's really going on.

Correct. They don't know. Anyone claiming they do is, at best, entirely misunderstanding.

== Doublepost prevention - post automatically merged: 31 May 2025 ==

Theres a lot of moving parts though in that case, and e.g. if the gate loses connection (I saw some stuff about TfW), or also if it's not a GWR gate (does GWR control all stations/gates all trains on this line go to)?

My feeling would be that it is simply the blacklist, unless someone has some scoop of GWR doing quite a bit of heavy lifting (and potential problems?)?

I'm pretty sure it's just a case of GWR having precisely the same devices as everyone else who's just got them. The member of staff just doesn't quite appreciate the subtleties of something they're new to.

 

[kevjs]

Think about how long it takes for a contactless payment to go through. You are typically looking at at least 0.5s if not 1 or 2 seconds. Multiply that by the number of people using each barrier and you can see the problem.

If TfL don't need to wait for a response from the bank now they wouldn't with "realtime" comms to the trains - IME the notification for TfL contactless comes between the gateline and escalators, Nottingham Contactless before I get to my seat in a 10m long bus.

Just need to hold off for x minutes after leaving the station before checking tickets to allow the data to sync - wouldn't even be beyond the realms of possibility of having a local sync at each station - i.e. the "train" downloads (hashed) details of the cards used to tap in at that station in a sensible time range, and the hand held terminal would show stations it successfully synced at (so no relying on waiting to hear from the banks)

 

[Vexed]

wouldn't even be beyond the realms of possibility of having a local sync at each station - i.e. the "train" downloads (hashed) details of the cards used to tap in at that station in a sensible time range, and the hand held terminal would show stations it successfully synced at (so no relying on waiting to hear from the banks)

Not very helpful for inspectors joining mid journey. But otherwise a good idea I'd say.

In the Netherlands they manage a live system with OVpay, so it's just a matter of how much we're willing to pay for getting Cubic to actually do something well for once so the barriers can send data live instead of at arbitrary intervals.

TfL is already rolling out mobile signal in tunnels which just leaves spotty signal on National Rail which can be handed by going back to the old system of retrospective back office checks.

 

[styles]

?? It really wouldn't cause a delay. It's very possible to communicate with a remote (London based) server in less than 10ms to send tap data.

Regardless though, they should be sending data in real time where possible - not batching it, or if they really need to batch it, send it every 10s or so. The data will be tiny (a handful of bytes) and it has key revenue enforcement implications. If it takes 10 minutes for the system to update it means that revenue enforcement people walking through trains don't know what's really going on.

It really would.

TfL was basically the test case for the card schemes making an exception for 'offline' contactless transactions based on transaction speed. The terminals themselves need to be online-capable though, to periodically sync data in the background, as part of the agreement TfL had with the card schemes.

Your authorisation transaction goes through a number of different systems, run by different people. Roughly speaking - cardholder -> merchant -> payment gateway -> acquirer -> (payment processor ->*) -> card issuer -> all the way back.

At each stage the authorisation can be declined. The merchant (TfL) might have a denylist for blocked card for example, the card issuer might say sorry not enough funds, etc. You cannot do all of that in 10ms. If it only took 10ms, card terminals when you pay by contactless would show you a green tick instantly. They don't, because it takes longer than that.

To give just one example of where it could go even further wrong doing online transactions - I used to work for a payment processor, and we would wait 2 seconds for a response from a card issuer. So let's say Monzo (one of our clients at the time) had an issue with their API and it was timing out. That's 2 seconds per Monzo passenger trying to get through the barriers if you do an online transaction. There's an argument that that wouldn't just be inconvenient - at some stations at certain times of day that might even be dangerous.

* Payment processors not required for all transactions, depends on acquirer and issuer.

There's a more detailed case study here https://www.ukfinance.org.uk/system/files/UK-Finance-Contactless-Transit-EMV-Framework.pdf

 

[Sonic1234]

But is the current system good enough? Not perfect maybe, but tolerable? Most people would believe contactless can be inspected, so you've got security through obscurity. If you haven't tapped in, you have to pay a max fare, it's not like you get away with it. How many ungated to ungated flows are there with decent passenger numbers within London?

Inspections within the London zones are incredibly rare anyway (I'm averaging one per 6 years, and that was only a "visual check" i.e. present something that approximates a card or ticket). It's the inspectors that are missing, not the payment tech.

 

[Vexed]

It really would.

TfL was basically the test case for the card schemes making an exception for 'offline' contactless transactions based on transaction speed. The terminals themselves need to be online-capable though, to periodically sync data in the background, as part of the agreement TfL had with the card schemes.

Your authorisation transaction goes through a number of different systems, run by different people. Roughly speaking - cardholder -> merchant -> payment gateway -> acquirer -> (payment processor ->*) -> card issuer -> all the way back.

At each stage the authorisation can be declined. The merchant (TfL) might have a denylist for blocked card for example, the card issuer might say sorry not enough funds, etc. You cannot do all of that in 10ms. If it only took 10ms, card terminals when you pay by contactless would show you a green tick instantly. They don't, because it takes longer than that.

To give just one example of where it could go even further wrong doing online transactions - I used to work for a payment processor, and we would wait 2 seconds for a response from a card issuer. So let's say Monzo (one of our clients at the time) had an issue with their API and it was timing out. That's 2 seconds per Monzo passenger trying to get through the barriers if you do an online transaction. There's an argument that that wouldn't just be inconvenient - at some stations at certain times of day that might even be dangerous.

* Payment processors not required for all transactions, depends on acquirer and issuer.

There's a more detailed case study here https://www.ukfinance.org.uk/system/files/UK-Finance-Contactless-Transit-EMV-Framework.pdf

There's no reason the batched card authorisations need to happen at the same time as recording to an internal TfL database. I think mrmartin was assuming 10ms is for TfL's internal database (which is realistic imo) and not card auths, which can keep the same system as used now.

Sure, it would be good to know if a card has declined, but most of the time simply knowing it's tapped in is enough.

 

[J663738]

Not sure if I have the wrong end of the stick here, but your contactless cards stores the last few entries. An RFID reader can see them. When I tried the new TfW PAYG contactless I was worried that a list of these purchases would come up, so when I presented my credit card for checking by the conductor, he got a special reader out and and asked what he sees on it. He showed me all he gets is a green light and a beep if the transaction is on the card, i.e. it has indeed been tapped in. Couldn't GWR set their readers to scan for GWR and TfL codes?

 

[JamesT]

Not sure if I have the wrong end of the stick here, but your contactless cards stores the last few entries. An RFID reader can see them. When I tried the new TfW PAYG contactless I was worried that a list of these purchases would come up, so when I presented my credit card for checking by the conductor, he got a special reader out and and asked what he sees on it. He showed me all he gets is a green light and a beep if the transaction is on the card, i.e. it has indeed been tapped in. Couldn't GWR set their readers to scan for GWR and TfL codes?

I believe the transaction history is very limited, if it’s there at all. Visa disable it by default with their cards. It also doesn’t include the merchant, so you couldn’t identify taps like that.

 

[J663738]

I believe the transaction history is very limited, if it’s there at all. Visa disable it by default with their cards. It also doesn’t include the merchant, so you couldn’t identify taps like that.

Ok, so I suppose the only other way the conductors device works is by having it receive a list of cards using some proprietary check sum type code on the 16 digit and cvc etc. They could be done in batches across the network. Would only be tiny amounts of real data transmitted. The conductors device would sync the data every few minutes and check the scanned credit card was on the list, I have seen them check a card and it not work and the conductor says he will come back and check again.
As an aside I bought sum duty free on board an Easyjet flight a few years back, it was horribly delayed, did not land until 3am. The items never appeared on my credit card, I suppose the flight attendant forgot to sync the card reader's data when they landed.
But trains unlike aircraft generally have decent or at least some data connectivity, even in mid Wales.

 

[swt_passenger]

Not sure if I have the wrong end of the stick here, but your contactless cards stores the last few entries. An RFID reader can see them. When I tried the new TfW PAYG contactless I was worried that a list of these purchases would come up, so when I presented my credit card for checking by the conductor, he got a special reader out and and asked what he sees on it. He showed me all he gets is a green light and a beep if the transaction is on the card, i.e. it has indeed been tapped in. Couldn't GWR set their readers to scan for GWR and TfL codes?

We’ve had numerous previous threads about this and it has always been said the TfL system cannot and does not write anything back to a contactless card, ie there’s no ‘touch in’ to look for on the card.

 

[Starmill]

We’ve had numerous previous threads about this and it has always been said the TfL system cannot and does not write anything back to a contactless card, ie there’s no ‘touch in’ to look for on the card.

Indeed. The card may well be given a counter every time it's touched but not where or broken down by merchant.

== Doublepost prevention - post automatically merged: 1 Jun 2025 ==

Ok, so I suppose the only other way the conductors device works is by having it receive a list of cards using some proprietary check sum type code on the 16 digit and cvc etc. They could be done in batches across the network. Would only be tiny amounts of real data transmitted. The conductors device would sync the data every few minutes and check the scanned credit card was on the list, I have seen them check a card and it not work and the conductor says he will come back and check again.
As an aside I bought sum duty free on board an Easyjet flight a few years back, it was horribly delayed, did not land until 3am. The items never appeared on my credit card, I suppose the flight attendant forgot to sync the card reader's data when they landed.
But trains unlike aircraft generally have decent or at least some data connectivity, even in mid Wales.

It doesn't do any of that though does it? All it does is checks the card is valid. That means it's working, in date, an accepted card type, and not one of the cards on the banned list. It then records the card's ID as tapped. If the first tap has arrived it may show on the device, if it hasn't, it will accept it without showing the tap.

 

[J663738]

It doesn't do any of that though does it? All it does is checks the card is valid.

Ok I will try this out, tap in with one credit card and present another valid card to the conductor for them to check.

PS How do you know TfW don't receive data from the tap in devices?
If the system is the way you say, it would be liable to fraud on a grand scale.

 

[Starmill]

which has many restrictions and isn't feasible to make use of on a regular basis

Anyone caught abusing this would get all their cards banned pretty quickly. Serial offenders would be likely to be prosecuted or investigated for fraud. The only real issue is that there aren't enough ticket checks. TfGM will charge £60 for a failed touch in.

== Doublepost prevention - post automatically merged: 1 Jun 2025 ==

Ok I will try this out, tap in with one credit card and present another valid card to the conductor for them to check.

I would strongly advise against this as you're likely to be charged and risk your card being banned.

== Doublepost prevention - post automatically merged: 1 Jun 2025 ==

If the system is the way you say, it would be liable to fraud on a grand scale.

It isn't.

 

[mrmartin]

There's no reason the batched card authorisations need to happen at the same time as recording to an internal TfL database. I think mrmartin was assuming 10ms is for TfL's internal database (which is realistic imo) and not card auths, which can keep the same system as used now.

Sure, it would be good to know if a card has declined, but most of the time simply knowing it's tapped in is enough.

Yes exactly. Also, as I said there's no reason the barriers couldn't be set to do online authorization at less busy times and the current system at peak times, maybe counting the number of taps over the past 10 minutes and if it is over a threshold doing the current "light" check. Obviously people could only enter stations at busy times to get round it but it would be hugely inconvenient.

I suspect there is already industrial fraud going on with this. See here: https://www.msn.com/en-za/news/othe...n-3-500/ar-AA1FFDon?ocid=finance-verthp-feeds

This is the moment a fare dodger was told he owes more than £3,500 in unpaid ticket costs after avoiding charges for over a year while using a 'card his friend gave him'.

The man had been using the bank card for over a year - despite having no money on it - when he was caught by TfL investigators at Surrey Quays station in London's docklands.

While the card had been accepted by the ticket reader each time, it had later resulted in a payment failure.

This meant he was able to force the exit gates to open at a station without having to pay the TfL travel charge, racking up thousands of unpaid fees.

It's probable there's much more of this going on.