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 don't know enough about how these things work, but if a card/device is presented to a RID then the RID should definitely announce itself as a transit device. If it doesn't then that's a serious flaw.
I don't know enough about how these things work, but if a card/device is presented to a RID then the RID should definitely announce itself as a transit device. If it doesn't then that's a serious flaw.
The Manchester Metrolink ones definitely do not. If you use a different card for express transit and default payment, you need to explicitly select the correct card for inspection. There is suggestion upthread that the TfL ones have the same shortcoming.
It's only an issue for a minority as most people set the same card as for express transit and default payment.
The Manchester Metrolink ones definitely do not. If you use a different card for express transit and default payment, you need to explicitly select the correct card for inspection. There is suggestion upthread that the TfL ones have the same shortcoming.
It's only an issue for a minority as most people set the same card as for express transit and default payment.
I mean it would never have occurred to TfL, a transport provider, checking payment for transport, on said transport itself to set their checking device to the appropriate mode for transport transactions, would it?
But no, how dare the pesky customer use the RFID facilities of their device as designed. Off to court they go.
I note that there was a previous TfL FoIA response to this, but the response (in my view) entirely misses the point the requester was trying to make, and simply brushes off the concerns: https://www.whatdotheyknow.com/request/applegoogle_pay
I've actually had sight of the datasheet for the hardware which I'm led to believe powers the RID2 and I can't see anything there which would suggest ECP support, but it's possible it's supported and just not documented.
Hopefully the response will shed some proper light on the current state of this.
@TigerCap I've had a response from TfL as follows:
The RID is designed to process the card presented to it during inspection and currently, this does not factor in Apple express mode. Customers must therefore present the correct card.
If they have been penalised - if they contact TfL’s customer services, they will look into it and where applicable refund and unblock the card.
@Adam Williams I've followed your request and will await responses eagerly. In my opinion this is a serious design flaw. I'll be writing about it later.
I really don't think this is the major flaw it's being made out to be. At the end of the day, the incident in question in this thread transpired due to user error. How is this any different to being inspected with your physical wallet and presenting the incorrect card in error?
Is it now unreasonable to expect a passenger to be aware of which card they are paying with?
My personal worry is when the battery is dead a customer isn't able to validate their payment (as said in the FOI linked upthread), it beggars belief that the Transit Mode has been advertised with the benefit of still working after the battery dies, conveniently omitting you're pretty much ****ed if you run into a RPI.
I really don't think this is the major flaw it's being made out to be. At the end of the day, the incident in question in this thread transpired due to user error. How is this any different to being inspected with your physical wallet and presenting the incorrect card in error?
So it's user error to be told that all you need to do is touch your phone on a reader to validate it and open the gates, but not be told that if your device is checked you have to do a lot more than just touch it on the device?
My personal worry is when the battery is dead a customer isn't able to validate their payment (as said in the FOI linked upthread), it beggars belief that the Transit Mode has been advertised with the benefit of still working after the battery dies, conveniently omitting you're pretty much ****ed if you run into a RPI.
The RID is designed to process the card presented to it during inspection and currently, this does not factor in Apple express mode. Customers must therefore present the correct card.
So it's user error to be told that all you need to do is touch your phone on a reader to validate it and open the gates, but not be told that if your device is checked you have to do a lot more than just touch it on the device?
It's unreasonable to expect a passenger to have to react in two different ways when travelling using CPAY.
So it's user error to be told that all you need to do is touch your phone on a reader to validate it and open the gates, but not be told that if your device is checked you have to do a lot more than just touch it on the device?
The user selects the card they want to use for this feature when they set up their phone. From that point onwards, the onus is on them to remember which card it is they are using to pay. It's not like Express Transit Mode is enabled by default or forced upon a user, the user ultimately decides they want to use it and they select the card they want to use as well.
OP, in error, presented the wrong card to Southeastern inspectors, but later presented the correct card to LU RPIs.
From that point onwards, it is not unreasonable for the passenger to expect that that preference will actually work for transport transactions - including when their payment is checked by an RPI employed by the transport authority.
The user selects the card they want to use for this feature when they set up their phone. From that point onwards, the onus is on them to remember which card it is they are using to pay. It's not like Express Transit Mode is enabled by default or forced upon a user, the user ultimately decides they want to use it and they select the card they want to use as well.
Do you work for Apple? Why are you trying to defend a pretty serious fault with the specification of this feature? Will you stand up in court and defend someone who ends up there because their phone ran out of battery but they still managed to pay for their journey correctly?
The user selects the card they want to use for this feature when they set up their phone. From that point onwards, the onus is on them to remember which card it is they are using to pay.
You are quite spectacularly missing the point here.
At the ticket barrier, you touch your phone against the readers and the readers will pick up the card selected to express transit and apply the touch to that card.
At a ticket inspection, you touch your phone against the reader and the reader will pick up the default payment card and apply the touch to that card.
The issue isn't that the user has forgotten which card is which. The issue is that one reader looks at one card and another reader looks at another card.
This probably isn't an issue where the express transit and the default payment cards are the same. But this is not a given. I have eight cards in my Apple Wallet. I don't use express transit (I'm actually old school and use a physical credit card) but, if I did, it is likely that my express transit card wouldn't be the same as my default payment card.
You are quite spectacularly missing the point here.
At the ticket barrier, you touch your phone against the readers and the readers will pick up the card selected to express transit and apply the touch to that card.
At a ticket inspection, you touch your phone against the reader and the reader will pick up the default payment card and apply the touch to that card.
The issue isn't that the user has forgotten which card is which. The issue is that one reader looks at one card and another reader looks at another card.
This probably isn't an issue where the express transit and the default payment cards are the same. But this is not a given. I have eight cards in my Apple Wallet. I don't use express transit (I'm actually old school and use a physical credit card) but, if I did, it is likely that my express transit card wouldn't be the same as my default payment card.
The issue isn't that the user has forgotten which card is which. The issue is that one reader looks at one card and another reader looks at another card.
The fact that we're several dozen posts in and still there are people unable to see what a fundamental design flaw in the RPI's reader this is should prepare everyone for the waves of misunderstanding to come when TOCs/TfL are challenged to resolve it.
If this was a banking industry issue they'd be on it, but the rail industry appears to be run by dinosaurs who fail to understand anything vaguely 21st century whilst blaming the (paying) customer and shouting "but we've always done it that way".
Time to get a grip folks and bin those readers immediately.
Or if they do keep them, the staff need to be pointing it out to each customer who offers a phone before they scan, so the correct card can be selected.
Thanks all for your replies and further interest in this. As suggested above by @Mattplans I have uploaded the first appeal letter I sent off, along with Penalty Services' rejection letter, and my draft second round appeal letter (now cut to the bone!). Also included is the journey and payment history for the day in question, which I also sent to PS for the first round. All comments gratefully received and thanks again for your help.
Attachments
1st round appeal letter - redacted.pdf
20.7 KB
· Views: 8
Appeal Outcome-SETAP0573553 - redacted.pdf
109.1 KB
· Views: 8
2nd round appeal letter - 1.0.docx
15.6 KB
· Views: 16
Journey history breakdown - 14th April - redacted.pdf
The second appeal letter is certainly to the point. It will probably also get rejected. You can then appeal a third time at which point all corespondance is reviewed by a different team. They do sometimes come to a different conclusion. It might then be time to include what we've learnt about the Express Transit and RID incompatibility. Do come back for advice as to what to include. Also, if you get responses from the second penalty fare I would do exactly the same.
Thanks @MikeWh , will do. Penalty Services have contacted me to say they have a high volume of appeals at the moment so the second penalty fare (28 April) may take a while to come through. Presumably if that one is successful it would be helpful to include it in any correspondence if a third appeal is needed for the 14 April PFN, as it is exactly the same scenario.
These Regulations make provision for the charging of penalty fares for the failure to produce, when required to do so, a ticket or other authority authorising a person to travel by train or to be present in a compulsory ticket area at a station.
@blimmo Interesting. That's how I would interpret it as well, although the 28 April PFN appeal was received by them on 8 May, so they still have 8 days until 29 May to come back to me. That said, if they do have a backlog and are under pressure to get through it then I suspect it will be speedily rejected given it's the first round.
== Doublepost prevention - post automatically merged: ==
Hi all, just posting to update that I’ve now had a response from Penalty Services in relation to the PFN issued on 28 April, and I have been successful! Very pleased to have one of them dealt with at least.
Annoyingly I didn’t see the email from PS until I had sent off the second round appeal for the 14 April PFN, otherwise I would have included it, but I will keep it in reserve for a third round if necessary.
The general problem is one for London Travelwatch, who should insist on an audit (or failing that, advertising/mailshots) to determine if anyone else was affected and just paid up or paid maximum fares and is due compensation.
A couple of PowerPoint slides usually does for intellectually challenged management .
A diagram showing a ticket barrier correctly reading phones in various configuration modes contrasted with the RPI's device behaving like a Tesco checkout reading the same phones should suffice. Once the penny drops that the read is wrong, leading to incorrect card numbers in the system, they should be able to grasp how things go badly wrong from there onwards.
Does the banking industry have a contactless payments working group, or similar, that this problem could be flagged with as well?
The problem isn't really about contactless payments. it's about how Apple Express Pay, or whatever it's called, does or doesn't work. If you take that out of the equation there isn't a problem.
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.