There are some interesting issues with the old oyster system when handling certain routes that involve out of station interchanges.
Out of station interchanges effect make two sets of barriers behave like they’re part of the same physical station, allowing you to temporarily exit the system, re-enter, but only get charged once, as if you never exited the system at all.
On the old oyster system this plays very badly with how the system handles you tapping in and out at the same station, at the start and end of a single journey. The Oyster systems assumes that you’ve made two trips, and not tapped out one way, and not tapped in the other way, and thus charges you two maximum fairs. Normally this isn’t an issue, but with out-of-station interchanges, it’s possible for you make a journey, leave the station, re-enter the station 20-30mins later, for your return journey (say you went to pick something up, and then went straight home), get caught within the out-of-station interchange, which effectively connects your return journey with your outbound journey. On the Oyster system, the out-of-station interchange is implemented by the re-entry barrier basically updating your card so it looks like you never left the system at all, as a consequence, when you tap out at your home station, the tap-out barrier thinks you’ve made two trips without properly tapping in and out, and charges you two maximum fairs.
With the contactless system, every single tap in and out is recorded by the barriers in their backend system, and an end of day batch system then looks at all of your tap ins and outs, and computes your final fair. Because it can see every single tap, it’s capable of recognising that you made two legitimate journeys, that shouldn’t be linked to by the out of station interchange, and thus charge you two correct fairs. Unlike the Oyster system, which has to make fair charging decisions at each tap, and due to limited memory on the card, can’t accurately track every single tap, as a result it has to be more aggressive in it fair calculation approach, otherwise it would be trivial to exploit its limitations to defraud TfL.
Although even the Oyster system will try and correct these issues. There are batch jobs that run on all the uploaded tap data collected by the barriers themselves, and those jobs do their best to try and spot errors like this, and perform automatic refunds. But it harder to perform those refunds because somehow the system has to the get the data on to the physical Oyster card, which uploading the patch into the barriers the system thinks you’re likely to use, so your card can be patched on the tap there.