Home |
Search |
Today's Posts |
![]() |
|
London Transport (uk.transport.london) Discussion of all forms of transport in London. |
Reply |
|
LinkBack | Thread Tools | Display Modes |
|
#1
![]() |
|||
|
|||
![]()
In message , at 10:34:27 on Wed, 29 Feb
2012, Stephen Sprunk remarked: There's a proposal to do *daily* billing via paywave credit cards for travel in London, but I don't know how they propose to "inspect" the ticket, because you can't 'load' one onto a credit card. I suppose they'd need to use your credit card number to make an enquiry from their own merchant account, to confirm you'd "touched in" recently. Depending on how the fare scheme is organized, it's possible the readers could just record the card numbers they "see" during the day and upload them to a central server at the end of the day; the central server would then figure out the correct fare(s) to charge for the day, based on the when(s) and where(s) each card had been "seen". That's how it's expected to work - but spot-checks by inspectors on trains will need access to that "recently seen" list, so it'll probably be done in real time. Unless they flag such a credit card as "checked for fare evasion today", and if it doesn't show up later as having been previously "seen" at a gate, charge a penalty fare. For instance, in many places there are daily and monthly passes; the logical way to handle that with daily billing is to charge the daily rate for the first several days the card was "seen" each month and then stop billing when the monthly rate is reached. That's the kind of capping algorithm they run in London, but on a daily basis (adding up single fares until it reaches the cost of an "all day" pass). I don't think there's a proposal to try to consolidate a week or month of travel. Likewise, if there is a single-ride rate, then within a single day the single-ride rate would be charged each time the card was "seen" until the daily rate was met. Yes, like that. But there's also a complicated set of timeouts for individual journeys, to stop you (eg) touching in near home in the morning, and out again at the next nearest station in the evening, and only being charged one short-distance fare rather than two long distance ones. -- Roland Perry |
#2
![]() |
|||
|
|||
![]() On Feb 29, 5:06*pm, Roland Perry wrote: In message , at 10:34:27 on Wed, 29 Feb 2012, Stephen Sprunk remarked: There's a proposal to do *daily* billing via paywave credit cards for travel in London, but I don't know how they propose to "inspect" the ticket, because you can't 'load' one onto a credit card. I suppose they'd need to use your credit card number to make an enquiry from their own merchant account, to confirm you'd "touched in" recently. Depending on how the fare scheme is organized, it's possible the readers could just record the card numbers they "see" during the day and upload them to a central server at the end of the day; the central server would then figure out the correct fare(s) to charge for the day, based on the when(s) and where(s) each card had been "seen". That's how it's expected to work - but spot-checks by inspectors on trains will need access to that "recently seen" list, so it'll probably be done in real time. Unless they flag such a credit card as "checked for fare evasion today", and if it doesn't show up later as having been previously "seen" at a gate, charge a penalty fare. EMV-specification contactless cards will apparently allow a small bit of read/write space (i.e. on the card itself) to be used by public transport undertakings for the purpose of recording that a card has been validated - I dunno the details, but at the very least I'd think the data recorded would have to include date/time and location of validation. Of course this raises all sorts of interesting questions as to how this will work - e.g. how do different public transport undertakings play nicely with each other on these cards (maybe they don't need to, the only important thing is the last validation) - but the point is that spot-checks by inspectors won't need real-time access to the central database to check if a card has been validated or not, as the card itself will hold the answer. For instance, in many places there are daily and monthly passes; the logical way to handle that with daily billing is to charge the daily rate for the first several days the card was "seen" each month and then stop billing when the monthly rate is reached. That's the kind of capping algorithm they run in London, but on a daily basis (adding up single fares until it reaches the cost of an "all day" pass). I don't think there's a proposal to try to consolidate a week or month of travel. Actually, there have indeed been proposals for 'account based' systems made by TfL. I'd imagine that if such a system was to come about, then a punter would have to actively opt-in to it, and I'd also think that the time windows used to calculate a potential weekly or monthly cap would have to be set universally (e.g. a calendar month, or a week that runs Monday-Sunday or whatever). Likewise, if there is a single-ride rate, then within a single day the single-ride rate would be charged each time the card was "seen" until the daily rate was met. Yes, like that. But there's also a complicated set of timeouts for individual journeys, to stop you (eg) touching in near home in the morning, and out again at the next nearest station in the evening, and only being charged one short-distance fare rather than two long distance ones. |
#3
![]() |
|||
|
|||
![]()
In message
, at 11:44:01 on Wed, 29 Feb 2012, Mizter T remarked: how do different public transport undertakings play nicely with each other on these cards That's what ITSO is about, and currently we've yet to find any interoperability between cards from different bits of the same company, let alone from one to another! -- Roland Perry |
Reply |
Thread Tools | Search this Thread |
Display Modes | |
|
|