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.